Re: Range requests and content encoding

On 22 Dec 2015, at 1:28 pm, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> RFC 7233 does not mention content encoding at all.  Same for transfer
> encoding.  I assume that is because this is completely unspecified and
> therefore completely unreliable, however, for my sanity...

206's semantics are defined in <http://httpwg.github.io/specs/rfc7233.html#status.206>:

"""
The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges found in the request's Range header field (Section 3.1).
"""

Note "selected representation", which is defined in <http://httpwg.github.io/specs/rfc7231.html#representations> as:

"""
An origin server might be provided with, or be capable of generating, multiple representations that are each intended to reflect the current state of a target resource. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to a given request, usually based on content negotiation. This "selected representation" is used to provide the data and metadata for evaluating conditional requests [RFC7232] and constructing the payload for 200 (OK) and 304 (Not Modified) responses to GET (Section 4.3.1).
"""

So, Content-Range operates upon the selected representation -- which would include any Content-Encodings.

Transfer-Encoding is defined to operate on the message body in <http://httpwg.github.io/specs/rfc7230.html#message.body>, which says it is removed to get to the message payload. 



> My reading is that a 206 response includes ranges of the encoded
> message, and that the content-encoding applies to the complete message
> body prior to being split into ranges.  Thus, if I had a "x2" content
> encoding that turned "Hello World!" into "HHeelllloo  WWoorrlldd!!",
> asking for bytes 3-5 would get you "eel" and not "llo".

Correct.


> The text in Section 4.1 suggests that you would not include a
> Content-Encoding header field if the client used If-Range on the
> expectation that they already know.  That seems pretty dangerous, but
> it's consistent with the idea that you are repairing a larger message.

... as per <http://httpwg.github.io/specs/rfc7233.html#combining.byte.ranges>.


> On the other hand, I have to assume that a Transfer-Encoding applies
> *after* the range request.
> 
> p.s., I've opened https://github.com/httpwg/http11bis/issues/11 for this.
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 22 December 2015 04:53:39 UTC