W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: ETags vs Variants, was: Revising RFC2616 - what's happening

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 24 Oct 2006 00:15:35 +0200
To: David Morris <dwm@xpasc.com>
Cc: ietf-http-wg@w3.org
Message-Id: <1161641735.29533.116.camel@henriknordstrom.net>
mån 2006-10-23 klockan 10:19 -0700 skrev David Morris:

> Encodings are supposed to be lossless ... based on my memory of the
> discussion and not reading the spec recently, the spirit of ETag and
> variants is that an encoding doesn't change the actual underlying entity.

Well, many aspects of the protocol in fact relies on ETag being unique
per response entity variant, not per original object version before
encoding.

 a) Caching of server driven negotiation logics (i.e. Vary), which uses
If-None-Match to deduce the logics applied by the server.

 b) Range merging and If-Range. Ranges is in the encoded data, not the
original.

Also the protocol as such does not guarantee that content-encoding is
lossless, no more than translations between languages is semantically
lossless. In both the the content is supposed to have the same semantic
meaning. The content-encoding is opaque to caches as they are not
required (or even supposed) to implement decoding or encoding on the
fly, only forwarding of the response as-is.

Also Content-Encoding is defined as an end-to-end entity header, which
the proxy is not supposed to muck around with. A non-transparent proxy
MAY but then has to take the full responsibilities, just as it may
perform lossy transformations on the data to reduce image resolutions
etc.

In the RFC Accept-Encoding is defined as one of many metrics for
server-driven content negotiation. It's governed by the same rules as
Accept, Accept-Language, Accept-Language, and any other headers used by
the server to decide what content to respond with. The end result of all
these decisions taken by the server is an response entity uniquely
identified by ETag, and to some extent Content-Location (the two has a
complex relation to each other, mainly related to cache invalidation on
updates).


This can be compared to the Transfer-Encoding schemes which is applied
hop-by-hop on the actual HTTP message transport with no semantic meaning
at all. Transfer-Encoding does not (MUST NOT) change ETag or any other
entity headers. Content-Encoding MUST change ETag.

Regards
Henrik

Received on Monday, 23 October 2006 22:15:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:53 GMT