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

From: Julian Reschke <[email-masked]>
Date: Thu, 01 Apr 2010 15:40:50 +0200

On 26.03.2010 00:32, Julian Reschke wrote:
> Hi,
>
> here's a proposal that would partly address
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/39>; after the
> introduction to entity tags, let's add an example that makes it crystal
> clear that entity tags may not be shared between responses negotiated on
> Accept-Encoding:
> ...

Now committed as <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/800>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 01 Apr 2010 15:40:22 +0200

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

Best regards, Julian

---

From: Jamie Lokier <[email-masked]>
Date: Thu, 1 Apr 2010 23:14:55 +0100

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

-- Jamie

---

From: Yves Lafon <[email-masked]>
Date: Fri, 2 Apr 2010 07:59:22 -0400 (EDT)

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

         ~~Yves

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 2 Apr 2010 22:25:34 +0100

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

> 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

---

From: Nathan <[email-masked]>
Date: Fri, 02 Apr 2010 23:18:07 +0100

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

Last time I asked the following (about 2 weeks back):

"What about cache's giving back the wrong media-type, would a change in
media-type be a semantic change of such magnitude that a weak entity tag
couldn't be used (or would be misleading)?"

Since then, a few simple mental use-cases for conneg with weak entity
tags have crossed my mind.

Same document / different Languages; would a cached german document
suffice when the user wanted an english one (and the server had one)?
- imo, no

Same "content" different mediatype text/text vs text/html; would a
cached html do when the user wanted text - debatable but swap that for
rdf & svg and i think the answer is no.

I continued this on with all the Accept headers and came to the same
conclusions; however Content-Encoding is the grey area for me I'm afraid.

Personally, not that it means anything, I'd be happy to use weak entity
tags only for when a minor change occurs to a representation; such as
stripping whitespace, fixing a (minor) typo, or swapping new line
terminators. For everything else I think I'd rather be safe than sorry
and stay clear.

A secondary point, is that any sharing of weak entity tags across conneg
resources would indicate to me that each resource would need it's own
strong etag, whilst each conneg point would need a weak entity tag -
that feels wrong and the logistics of managing this entirely impractical
- especially when you consider that each representation more than likely
has a different update schedule.. effectively you'd always just have a
single weak entity tag for a conneg point that never changed, as in:

You have four representations which you negotiate across; thus these are
all semantically equivalent; update one of them only and the notion of
conneg indicates they are all still equivalent, thus a weak entity tag
still valid, however all caching would be broken - further after say 100
incremental updates to all resources; the weak etag would still be the
same - completely breaking caching.

Thus I can answer my own aforementioned question and say that a change
in media-type would be a semantic change that meant a weak entity tag
couldn't be used.

As for Content-Encoding and weak entity tags, the only thing I can think
that might influence it is range requests; if the byte offsets differ
between different encodings then they wouldn't be valid so a strong tag
would be needed.

?

Regards,

Nathan

ps: maybe I asked an invalid question!

---

From: Yves Lafon <[email-masked]>
Date: Tue, 6 Apr 2010 09:11:52 -0400 (EDT)

> does it require that equivalence could be determined by application

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

> semantically equivalent but not the same (i.e. suitable for weak etag

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.

> which is transparently decompressed in the context of its use does not.

Content-Encoding is not about transparent compression, Tranfer-Encoding 
is.

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

         ~~Yves

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Apr 2010 15:31:42 +0200

> application (server or client) can try to address. Better wordings

Indeed; and we have a separate ticket for *that*: 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/101>.

Best regards, Julian

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 6 Apr 2010 14:46:53 +0100

> Content-Encoding is not about transparent compression, Tranfer-Encoding 

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

> application (server or client) can try to address. Better wordings 

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

---

From: Yves Lafon <[email-masked]>
Date: Tue, 6 Apr 2010 10:30:38 -0400 (EDT)

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

Also the fact that implementations are not implementing Transfer-Encoding 
does not mean that it is right to consider Content-Encoding as being 
equivalent.

> semantic equivalence means for it's resources*.

For individual resources.

> say, application/x-tar...

Why? Also would rot13 apply?

> technical reason forbidding it.
No reason to forbid it, but if you rely on weak etag equivalence for 
different representations, expect it will break.

         ~~Yves

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 6 Apr 2010 15:49:31 +0100

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

> For individual resources.

Yes.

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Apr 2010 16:56:09 +0200

> you should be using strong etags instead for that.

For instance, the way you construct your representation may not 
guarantee binary identity, although the underlying resource is the same 
(think an XML database with a generic XML serializer, affecting, for 
instance, attribute order).

Best regards, Julian

---

From: Jamie Lokier <[email-masked]>
Date: Tue, 6 Apr 2010 16:22:46 +0100

>> different representations, expect it will break.

Changing attribute order *is* making a different representation.

Thus Julian's idea of when to use the same weak etags is recommended
against by Yves.

I happen to agree with Julian(*), but I'm really interested in when
Yves thinks it is appropriate to use same weak etags, given the
statement that it's unsafe to use them for different representations.

-- Jamie

ps. (*) Why my pov matches Julian's:

Instead of changing attribute order, what about different output
encodings at serialization time?  Note that the *input* XML database
might not even *have* a character encoding.  I think that is in the
same category as attribute order, because the underlying XML resource,
right down to the individual characters, is unchanged, although it's
clearly not binary identical.

If the underlying resource is the same for different character
encodings (Content-Type charset=), in what way is compression
(Content-Encoding) semantically different?  I think it isn't.

-- Jamie

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Apr 2010 17:37:22 +0200

> Thus Julian's idea of when to use the same weak etags is recommended

Nope.

It is a different representation (in that it may vary over time), but I 
wouldn't call it a different representation of a different *resource*.

> clearly not binary identical.

Absolutely.

> (Content-Encoding) semantically different?  I think it isn't.

I'm not sure, and I'm even not sure the answer matters.

We will need to change text to address 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/101> (please review 
the long history of this issue).

In particular, Roy said:

> A weak entity tag SHOULD change whenever the origin server considers prior representations to be unacceptable as a substitute for the current representation. In other words, an entity tag SHOULD change whenever the origin server wants caches to invalidate old responses.

Best regards, Julian

---

From: Nathan <[email-masked]>
Date: Tue, 06 Apr 2010 16:41:27 +0100

Jamie Lokier wrote:
> (Content-Encoding) semantically different?  I think it isn't.

Is this a change in semantics which the server considers to be
equivalent (semantically), or should/must the representation equivalence
be considered from a user-agent / cache perspective.

Would two representations with different content-encodings and character
encodings be valid replacements for each other at a cache?

"weak validators allow for more efficient caching of equivalent objects"

regards

---

From: Yves Lafon <[email-masked]>
Date: Tue, 6 Apr 2010 12:43:40 -0400 (EDT)

> you should be using strong etags instead for that.

Imagine a server side include in an HTML page with a datetime displayed 
for the user, the application can consider it meaningless, and use a weak 
ETag to signal that the page won't be byte-for-byte equivalent.

         ~~Yves