- From: Jamie Lokier <jamie@shareable.org>
- Date: Tue, 6 Apr 2010 14:46:53 +0100
- To: Yves Lafon <ylafon@w3.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>, nathan@webr3.org, HTTP Working Group <ietf-http-wg@w3.org>
Yves Lafon wrote: > >I cannot imagine what would fit the criteria, if compression of a type > >which is transparently decompressed in the context of its use does not. > > Content-Encoding is not about transparent compression, Tranfer-Encoding > is. In the *context* of a web browser receiving *text/html* and a few other things, Content-Encoding does in fact mean use transparent decompression, and Transfer-Encoding is rarely used for that (because it's not as widely supported). Besides, Transfer-Encoding is hop-by-hop - and therefore inappropriate when you don't want to load the intermediaries :-) > >I don't know what semantic equivalence means at all without context. > > Yes, semantic equivalence is at best fuzzy, and a property that only an > application (server or client) can try to address. Better wordings > welcomed :) Exactly, it's fuzzy, subject to interpretation, and application dependent. But more to the point, it's *up to the etag producer to decide what semantic equivalence means for it's resources*. There is no technical reason not to use the same weak etag for two different representations, if the etag producer decides that the representations are semantically equivalent by its own criteria. Thus I contend that in the application of a server sending text/html to a web browser, it's acceptable to decide that compressed and uncompressed Content-Encodings may share the same weak etag - and that is also perfectly reasonable in human terms because we know that the compression makes no important difference in that application. Of course I wouldn't claim they are semantically equivalent if it's, say, application/x-tar... And you don't *have* to use the same weak etags. But there is no technical reason forbidding it. -- Jamie
Received on Tuesday, 6 April 2010 13:47:23 UTC