Link: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/101
Origin: http://www.w3.org/mid/47767C72.6030507@onlinehome.de
Component: p4-conditional
From 13.3.3 Weak and Strong Validators:
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.
Note: One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.
An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible that the resource might be modified twice during a single second.
While in paragraph 1 "weak validator" is defined in terms of semantic equivalence, paragraph 3 qualifies modification time as "weak validator". But the second modification of a file within the same second may change the file into anything. There is no means to guarantee semantic equivalence in this case. Both this paragraphs are mutual exclusive.
The reason for this is the abstraction "weak validator" itself. While "validator" is a good abstraction from the details of Last-Modified and Etag, and also "strong validator" is quite clear, this can't work for "weak".
"weak validator" tries do build a common abstraction from two different, completely unrelated kinds of "weakness".
Weak etags: the weakness is not to guarantee byte-equivalence, but they guarantee semantic equivalence. Of course, the server needs some concept of semantic equivalence build in, to use weak etags. (Oh, and it would be fine, if the client would have the same idea about semantics.)
Last-Modified date: the weakness is the limited time resolution. It is *unreliable* (or not a validator at all), unless it meets some extra conditions. There is no concept of semantic equivalence whatsoever.
On consequence are the strange restrictions on "weak validators". Clients must only use them in conditional (full body) GET requests. This is reasonable for Last-Modified (if it does not meet the additional restrictions), but not at all justified for weak etags.
The only reasonable restriction on weak etags is not to use them in range requests. But a PUT with If-Match: W/"xxx" is perfectly ok.
I suggest to remove the term "weak validator" from the spec. Validator is either a Last-Modified Date or an Etag. Etags can be strong or weak. I should be made clear, that weak etags ore only meant to validate semantic equivalence and it should be clear, that everything said about semantic equivalence is related to weak etags.
Practical issue: Apache misuses weak etags when it can not create a strong one, due to the limited time resolution (and mtime is the main component of Apache's etags). This etags will *never* match. (IIS seems to do something similar.) Although I'm sure, this is not what weak etags are intended for, one could use the inconsistent definition in the spec to justify this (one has to be either a lawyer or a programmer to do so).
I don't know, if there is any application, that uses weak etags as they are intended (for validating semantic equivalence). But if there is, or will be, the above misuse will most likely create interoperability problems. WebDAV-clients (e.g. davfs2) already have problems to work around this wrong "weak etags".
remove the notion of "semantic equivalence" and replace it with "good enough, from the server's point of view". That is, a server is free to report a "match" on a weak validator if the server thinks an entity previously served with that validator is "good enough", from the server's point of view. Whether that's semantically equivalent doesn't need to come into the picture, except as an example of one reason why, even if something has changed, you might be content to let the client use old content.
-- http://www.w3.org/mid/002001c84d84$13e4c240$3bae46c0$@org
Proposal:
Remove the notion of "semantic equivalence" and replace it with (roughly) "good enough, from the server's point of view".
Proposal accepted.
Suggestion:
P4, section 3:
A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
two entities of a resource only if the entities are equivalent and could be substituted for each other with no significant change in semantics.
to:
... MAY be shared by two representations of a resource only if the origin server considers them to be semantically equivalent.
Section 5:
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.
Section 6:
In order to be legal, a strong entity tag MUST change whenever the associated entity value changes in any way. A weak entity tag SHOULD change whenever the associated entity changes in a semantically significant way.
to:
... A weak entity tag SHOULD change whenever the associated entity changes in a way that the server determines is semantically significant.
Proposed change for part 4.
I don't see how that addresses the issue of "semantically equivalent" being an untestable quality. What it should say is
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.
Note that this same pattern needs to be used in other cache descriptions, because 2616 mistakenly defines HTTP in terms of implementation rather than in terms of what the interface describes to the message recipient.