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