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

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.

I think it comes down to "if one document was used in place of the
other, for example shown in a browser, would it have essentially the
same meaning, differing only in unimportant details?"

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

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.

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

The question was about weak Etag, not strong.

The question of semantic equivalance is rather contextual - it depends
on the meaning that will be extracted from the document.  In the
context of web browsers, compressed text/* is transparently
decompressed and so I believe it to be semantically equivalent in that
context.

I don't know what semantic equivalence means at all without context.

-- Jamie

Received on Friday, 2 April 2010 21:26:04 UTC