Subject: RE: Range requests and content encoding

From: <[email-masked]>
Date: Tue, 5 Jan 2016 11:02:40 +0000

On Tuesday,22 December 2015 03:29 [email-masked]<mailto:[email-masked]> 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.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 6 Jan 2016 13:45:08 -0800

> On Jan 5, 2016, at 3:02 AM, [email-masked] wrote:
> 
> On Tuesday,22 December 2015 03:29 [email-masked] <mailto:[email-masked]> wrote:

The term entity-body is now referred to as either the payload body or the selected representation,
depending upon whether we are talking about an actual message.  Content-Encoding is defined in

https://tools.ietf.org/html/rfc7231#section-3.1.2.2 <https://tools.ietf.org/html/rfc7231#section-3.1.2.2>

and there is nothing ambiguous about it.  RFC7233 doesn't talk about it because it doesn't need to,
just like it doesn't need to talk about the other representation metadata (unlike the metadata that
impacts message framing, which it does talk about).

....Roy

---

From: <[email-masked]>
Date: Thu, 7 Jan 2016 10:12:20 +0000

Roy,

On Wednesday,06 January 2016 22:45, [email-masked] wrote:
> The term entity-body is now referred to as either the payload body or the
> selected representation, depending upon whether we are talking about an
> actual message.  Content-Encoding is defined in
>
> https://tools.ietf.org/html/rfc7231#section-3.1.2.2
>
> and there is nothing ambiguous about it.

It may not be ambiguous, but it's even more abstruse than in the old RFC2616.

> RFC7233 doesn't talk about it because it doesn't need to,

It may not _need_ to, but it wouldn't hurt to be more explicit. If it was unclear to Martin (an acknowledged contributor to RFC723x [1]), I'm confident it will be unclear to a lot of other folks.
On Tuesday,22 December 2015 03:29 [email-masked] 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.

You might recall Roy, that you already called out Martin for being confused when I brought this up back in March 2014 w.r.t. http/2:
On Mon, 24 Mar 2014 13:19:10 -0700 [email-masked] wrote:
> On Mar 24, 2014, at 10:04 AM, Martin Thomson wrote:
>> [snip]
>> As I said, I think that this is a confusion between two different but
>> oft-confused headers:
>>
>> Content-Encoding: gzip
>> Transfer-Encoding: chunked
>
> It seems you have confused them.  Transfer Encoding is something
> that can be added or removed by the protocol.  Content Encoding is
> metadata about the representation. ...

On the other hand we seem to be the only guys in the world who use range requests and gzip transfer encoding (considering gzip TE got axed from the mainline http/2 spec), so it doesn't matter anyway :)

-keith

[1] https://tools.ietf.org/html/rfc7230#section-10

> just like it doesn't need to talk about the other representation
> metadata (unlike the metadata that impacts message framing, which it does talk
> about).
>
> ....Roy