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

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

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

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

And you don't *have* to use the same weak etags.  But there is no
technical reason forbidding it.

-- Jamie

Received on Tuesday, 6 April 2010 13:47:23 UTC