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 https://www.google.com
fails with HTTP/2, too...

Best regards,
Ricki
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-users
FAQ: https://curl.haxx.se/docs/faq.html
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-10-29