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

Yves Lafon wrote:
> >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.

But the decision about how to use weak etags is *determined* by
application design choice.  HTTP only comes into what the consequences
of that choice are.  HTTP doesn't specify what choice to make in
technical terms, in the case of weak etags - it delegates that to
application design.

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

Yes.

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

Actually I may change my mind about that one: I was thinking that
semantically it's significant applications (that I'm thinking off)
want a gzipped tar file to behave differently from a non-gzipped one,
which is that they are saved differently.  But Content-Encoding: gzip
with Content-Type: application/x-tar is not how that is represented
anyway.  So I may change my mind.  Very contextual...

> Also would rot13 apply?

Yes if in context (determined by the application setting the etags)
the rot13'd version is considered semantically equivalent to the
non-rot13'd version.  No if not.

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

So back to an earlier query: When *would* you use weak etag
equivalence for different representations?  If never, do weak etags
have any purpose at all?  What would you use weak etags for?  Because
if you only use the same weak etag when representations are identical,
you should be using strong etags instead for that.

-- Jamie

Received on Tuesday, 6 April 2010 14:50:02 UTC