Re: Issue 39: proposed example for varying the etag based on conneg

On Tue, 6 Apr 2010, Jamie Lokier wrote:

> 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).

The application (the browser in this case) makes the Content-Encoding 
transparent to the HTML handler, ok. But that's an application design 
choice, and not related to HTTP interaction at all.

Also the fact that implementations are not implementing Transfer-Encoding 
does not mean that it is right to consider Content-Encoding as being 

> 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*.

For individual 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...

Why? Also would rot13 apply?

> And you don't *have* to use the same weak etags.  But there is no
> technical reason forbidding it.
No reason to forbid it, but if you rely on weak etag equivalence for 
different representations, expect it will break.

Baroula que barouleras, au tiéu toujou t'entourneras.


Received on Tuesday, 6 April 2010 14:30:44 UTC