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

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

         ~~Yves

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