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

On Fri, 2 Apr 2010, Jamie Lokier wrote:

> Yves Lafon wrote:
>> On Thu, 1 Apr 2010, Jamie Lokier wrote:
>>>> 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.
> The question was about *weak* etags.  Two things do not have to be
> identical for the purpose of weak etags - strong etags are used for that.
> "Semantically equivalent" for the purpose of *weak* etags is not well
> defined in FRFC2616, and seems to be left to interpretation.
> But it clearly does not mean "the same thing" or "they are equal", nor
> does it require that equivalence could be determined by application
> processing.

Yes, but my point was that those were the representations given by two 
different resources, in that case, weak or not, the ETags are completely 

> If two documents are byte-for-byte identical except for compression
> aren't sufficiently equivalent to fit your idea of "semantically
> equivalent", can you give an example of two things which *are*
> semantically equivalent but not the same (i.e. suitable for weak etag
> but not strong)?

Is the same rectangle area of pixels, but compressed in png and gif 
"semantically equivalent" or even "pixel equivalent" ?
The fact that there is an equivalence after the application uncompressed 
the byte received, or process the pixels to figure out that those are 
equals is something the application might want to know, but nothing that 
should be hinted at the HTTP level.

> 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 

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

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


Received on Tuesday, 6 April 2010 13:11:58 UTC