RE: Range requests and content encoding

On Tuesday,22 December 2015 03:29 martin.thomson@gmail.com<mailto: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...

>

> 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.

>

> [snip]

>

> On the other hand, I have to assume that a Transfer-Encoding applies

> *after* the range request.

>



As others pointed out, your assumptions are correct on both accounts. This was _explicit_ in the old RFC2616 by tracing the following sequence of logic...

- "The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The message-body differs from the entity-body only when a transfer-coding has been applied" RFC2616 Section 4.3 [1]

- "message-body = entity-body | <entity-body encoded as per Transfer-Encoding>" Section 4.3 [1]

- "entity-body := Content-Encoding( Content-Type( data ) )" RFC2616 Section 7.2.1 [2]

- "Byte range specifications in HTTP *apply to the sequence of bytes in the entity-body* ..." RFC2616 Section 14.35.1 [3] (emphasis added)

RFC 7230 provides a new definition of message-body and eliminates a definition for entity-body:
- "message-body = *OCTET" RFC7230 Section 3.3 [4]

- "Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), Transfer-Encoding is a property of the message, not of the representation ..." RFC7230 Section 3.3.1 [5]



Since RFC7230 eliminated a definition for entity-body, RFC 7233 now only includes this vague (and IMO ambiguous) assertion that _might_ lead one to understand that ranges only apply to the content-encoded representation.

- "A byte-range request can specify a single range of bytes or a set of ranges within a single representation." RFC7233 Section 2.1 [6]



IMO the ambiguity should be fixed.



-keith



[1] https://tools.ietf.org/html/rfc2616#section-4.3


[2] https://tools.ietf.org/html/rfc2616#section-7.2.1


[3] https://tools.ietf.org/html/rfc2616#section-14.35.1


[4] https://tools.ietf.org/html/rfc7230#section-3.3


[5] https://tools.ietf.org/html/rfc7230#section-3.3.1


[6] https://tools.ietf.org/html/rfc7233#section-2.1






This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.