cURL / Mailing Lists / curl-users / Single Mail


Re: --tr-encoding and HTTP/2

From: Tatsuhiro Tsujikawa <>
Date: Sun, 30 Oct 2016 17:42:48 +0900


On Sun, Oct 30, 2016 at 1:27 AM, 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."
> 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.
> And I'm still wondering why curl --tr-encoding
> fails with HTTP/2, too...
In HTTP/2, "TE" header field​ can take "trailers" only. "TE: gzip" is a
violation against HTTP/2 specification. HTTP/2 also deprecates
Transfer-Encoding stuff completely.

Perhaps, we should ditch "TE" from request header field when HTTP/2 is
used, just like we do for "Connection" header field already.

Best regards,
Tatsuhiro Tsujikawa

> Best regards,
> Ricki
> -------------------------------------------------------------------
> List admin:
> FAQ:
> Etiquette:

List admin:
Received on 2016-10-30