cURL / Mailing Lists / curl-users / Single Mail


Re: --tr-encoding and HTTP/2

From: Tony Aiuto via curl-users <>
Date: Mon, 31 Oct 2016 09:44:29 -0400

On Sat, Oct 29, 2016 at 12:27 PM, Ricki Hirner <> wrote:

> Hello,
> > If a service returns a different ETag simply because the request
> > allows different content encoding, that is a problem with the server.
> > ETags should only change when the object at the URL has different
> > content.
> As far as I understand it, this is not true. A (strong) ETag is unique
> "for the selected representation", which is also determined by the
> content coding.
> See RFC 7232 section 2.3 (ETag), and especially the example in section
> 2.3.3: /index has an ETag of "123-a" without gzip and "123-b" with
> Content-Encoding: gzip.
> It says this even explicitly: "Note: Content codings are a property of
> the representation data, so a strong entity-tag for a content-encoded
> representation has to be distinct from the entity tag of an unencoded
> representation to prevent potential conflicts during cache updates and
> range requests. In contrast, transfer codings (Section 4 of [RFC7230])
> apply only during message transfer and do not result in distinct
> entity-tags."
​I stand corrected. That is a significant change from RFC 2616, where it
mention content encoding (at least as far as I can see) in the ETag
I know of more than one service that calculates ETag based on the object
value treats content encoding more like a transfer encoding.

> Also, isn't this the whole difference between Content-Encoding and
> Transfer-Encoding? In my opinion, the only useful case of
> Content-Encoding is when you have statically compressed .gz files,
> which can then served with sendfile directly (taking the ETag from the
> .gz file, which is another one as of the original resource). In all
> other cases, Transfer-Encoding would make much more sense and at the
> moment, I'm wondering why everybody uses Content-Encoding instead.

​Possibly because so many things were implemented before the revision
​in the ETag specification. There are a lot of browsers out there who use
accept-encoding as a proxy for transfer encoding.

> And I'm still wondering why curl --tr-encoding
> fails with HTTP/2, too...
> Best regards,
> Ricki
> -------------------------------------------------------------------
> List admin:
> FAQ:
> Etiquette:

List admin:
Received on 2016-10-31