RE: Range requests and content encoding

Roy,

On Wednesday,06 January 2016 22:45, fielding@gbiv.com 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 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.

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 fielding@gbiv.com 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

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.

Received on Thursday, 7 January 2016 10:12:56 UTC