W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

RE: NEW ISSUE: weak validator: definition inconsistent

From: Larry Masinter <LMM@acm.org>
Date: Wed, 2 Jan 2008 13:11:44 -0800
To: "'Werner Baumann'" <werner.baumann@onlinehome.de>, <ietf-http-wg@w3.org>
Message-ID: <002001c84d84$13e4c240$3bae46c0$@org>

I don't think it is a good idea to remove the term, but it would be better
to define it more carefully, perhaps to 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.



> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
> On Behalf Of Werner Baumann
> Sent: Saturday, December 29, 2007 8:57 AM
> To: ietf-http-wg@w3.org
> Subject: NEW ISSUE: weak validator: definition inconsistent
> 
> 
>  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".
> 
> Werner
Received on Wednesday, 2 January 2008 21:12:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:35 GMT