Subject: Proposal for issue #101 (strong/weak validators).

From: Yves Lafon <[email-masked]>
Date: Fri, 14 Nov 2008 14:31:26 -0500 (EST)

Here is a proposed change for issue #101 [1], as the issue is more the 
definition of "weak validator", being linked to both unreliable 
identification of changes _and_ the will to signal only significant (read: 
semantic) changes.

In paragraph 5 of Part 4 [2], change:

    However, there might be cases when a server prefers to change the
    validator only on semantically significant changes, and not when
    insignificant aspects of the entity change.  A validator that does
    not always change when the resource changes is a "weak validator."

    Entity tags are normally "strong validators," but the protocol
    provides a mechanism to tag an entity tag as "weak."  One can think
    of a strong validator as one that changes whenever the bits of an
    entity changes, while a weak value changes whenever the meaning of an
    entity changes.  Alternatively, one can think of a strong validator
    as part of an identifier for a specific entity, while a weak
    validator is part of an identifier for a set of semantically
    equivalent entities.

=>

    However, there might be cases when a server prefers to change the
    validator only on semantically significant changes, and not when
    insignificant aspects of the entity change, or cases where the
    validator is use does not allow reliable identification of changes.
    A validator that does not always change when the resource changes
    is a "weak validator".

    Entity tags are normally "strong validators", but the protocol
    provides a mechanism to tag an entity tag as "weak".  One can think
    of a strong validator as one that changes whenever the bits of
    an entity changes, while a weak entity tag value changes whenever
    the meaning of an entity changes. Alternatively, one can think of
    a strong validator as part of an identifier for a specific entity,
    while an entity tag used as a weak validator is part of an identifier
    for a set of semantically equivalent entities.

Thoughts?

[1] <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/101>
[2] <http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-04#section-5>

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

         ~~Yves

---

From: Werner Baumann <[email-masked]>
Date: Fri, 14 Nov 2008 23:10:51 +0100

Yves Lafon wrote:
> identification of changes _and_ the will to signal only significant 
> (read: semantic) changes.
> 
>    [...]
> [2] 
> <http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-04#section-5>
> 

This does not resolve the contradiction.

"cases where the validator is use does not allow reliable identification 
of changes". In current practise this means changes within the same 
second and there is nothing that restricts the kind of changes that 
might occur.

"a weak entity tag value changes whenever the meaning of an entity 
changes. .. a weak validator is part of an identifier for a set of 
semantically equivalent entities" simply is not true for current practise.

Why do you want to promise or suggest some kind of semantic equivalence 
when arbitrary changes may happen without changing the weak etag?
Just make up your mind and either remove that "semantic equivalence" 
stuff or deprecate current practise.

A specification should not be intentionally ambivalent.

Werner

---

From: Yves Lafon <[email-masked]>
Date: Fri, 14 Nov 2008 18:45:50 -0500 (EST)

On Fri, 14 Nov 2008, Werner Baumann wrote:

> "cases where the validator is use does not allow reliable identification of 
> changes". In current practise this means changes within the same second and 
> there is nothing that restricts the kind of changes that might occur.

Well, ETag is always either explicitely weak to denote "semantic 
equivalence". The text was added to explicit the definition of "weak"ness 
of other validators that have intrisic issue in outlining changes (like 
Last-Modified).

> "a weak entity tag value changes whenever the meaning of an entity changes. 
> .. a weak validator is part of an identifier for a set of semantically 
> equivalent entities" simply is not true for current practise.
>
> Why do you want to promise or suggest some kind of semantic equivalence when 
> arbitrary changes may happen without changing the weak etag?

What do you mean by that? If a weak Etag is reused after a major change 
occured, then it is an server choice, and it should accept the (possibly 
bad) consequences, even if that change arise in the same second 
(as it is irrelevant to the use of Etags as validators, just relevant when 
last-modified is used as a validator).
That is why the proposed text talks about "semantic equivalence" only in 
the context of Etags validators, and not validators in general (which I 
agree was ambivalent).
Cheers,

         ~~Yves

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 15 Nov 2008 01:27:28 +0100

> second and there is nothing that restricts the kind of changes that 

I assume you by "current practise" mean the Apache ETag implementation?
There this is only true in very specific conditions. Most sub-second
changes do infact get properly reflected in the weak ETag. The server
application need to do some quite special things to not get the change
reflected in ETag or be very unlucky, unless ofcourse the ETag algorithm
has manually been degraded in quality (may be needed for replicated
cluster setups).

Yes, there is some cases where the simple algorithm used by Apache will
fail and emit the same weak ETag for two quite different objects, but in
real life use those is quite rare. In fact I would argue that it's
probably more likely the content gets updated while being sent, making
even their strong ETags "worthless", and the same for any server on any
OS where files may be updated while read by another application unless
you buffer the whole selected representation to calculate the ETag.

And no, it's not strictly compliant by Apache to return the same ETag
when the content is completely different, but the Apache team has
accepted this risk as the risk of this happening in any normal setup and
use is very low. In nearly all cases the kind of changes which the ETag
algorithm would miss is indeed of "weak semantic level".

Regards
Henrik

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 15 Nov 2008 09:11:22 +0000

Henrik Nordstrom wrote:
> real life use those is quite rare.

Rare, but the point of cache validators is to do what they are
specified to do all the time, not most of the time.

Imho, though, Apache's transmission of weak validators is reasonable
here; it's just an unusual interpretation of "semantic equivalence".
Just as long as nobody _uses_ them :-)

> In fact I would argue that it's probably more likely the content
> gets updated while being sent, making even their strong ETags
> "worthless", and the same for any server on any OS where files may
> be updated while read by another application unless you buffer the
> whole selected representation to calculate the ETag.

Sensible applications, on unix, replace files by renaming over the
original.  When a file is served, it is always the old contents or the
new contents, never a mix.

Not all applications are sensible, though, and you can't do this on Windows.

-- Jamie

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 15 Nov 2008 17:21:55 +0100

> new contents, never a mix.

Which would render a competely new weak ETag in Apache (on Unix), even
if the file timestamp and size is identical.

Regards
Henrik

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 17 Nov 2008 02:38:44 +0000

> if the file timestamp and size is identical.

Nearly always true, yes.  It's good enough but not cast iron.

It's is not guaranteed even on unix.  Firstly some filesystems have
synthetic inode numbers, which are generated at the time of stat()
call.  Secondly, if you modified the file *twice* in the same second
using rename-over, the original inode number can be recycled on any
unix filesystem.  Only by using the inode generation number (which NFS
uses) can you avoid this, and that's not generally available to user
processes.

-- Jamie