On Sat, Oct 29, 2016 at 12:27 PM, Ricki Hirner <r_at_hirner.at> 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
does
mention content encoding (at least as far as I can see) in the ETag
calculation.
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 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
>

-------------------------------------------------------------------
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-31