W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

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

From: Yves Lafon <ylafon@w3.org>
Date: Fri, 2 Apr 2010 07:59:22 -0400 (EDT)
To: Jamie Lokier <jamie@shareable.org>
cc: Julian Reschke <julian.reschke@gmx.de>, nathan@webr3.org, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.DEB.1.10.1004020752590.9905@wnl.j3.bet>
On Thu, 1 Apr 2010, Jamie Lokier wrote:

> Julian Reschke wrote:
>> On 26.03.2010 00:39, Nathan wrote:
>>> only feedback I can give is my immediate question:
>>>   can they share a weak entity tag?
>>> many regards,
>>> nathan
>>> ...
>> I don't see how... Would you consider the gzipped version of a
>> text/plain resource to be "semantically equivalent"?
> Yes, without a doubt they are semantically equivalent.  The compressed
> and uncompressed versions say exactly the same thing in different
> ways.  Their relationship is even purely mechanical and reversible.
> Isn't that about as semantically equivalent as you can get?

No they are not. At least not directly. The fact that it is compressed is 
a property of the entity, in that way it is not the same thing as the 
uncompressed text.

Same thing for an image of CT images/gif and the exact same image with a 
CT of image/png, they are not equivalent unless the application do some 
extra processing to figure out they are equal.

If you want the compression to be transparent, it has to be done at the 
connection level using TE/Transfer-Encoding, and in that case the ETag wil 
be the same (which is the second example in Julian's proposal)

See also the definition of Content-Location [1] which hints that those are 
two different resources that might have different URI to access them.

    A server SHOULD provide a Content-Location for the variant
    corresponding to the response entity, especially in the case where a
    resource has multiple entities associated with it, and those entities
    actually have separate locations by which they might be individually
    accessed, the server SHOULD provide a Content-Location for the
    particular variant which is returned.

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-09#section-5.7

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

Received on Friday, 2 April 2010 11:59:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:53 UTC