Re: NEW ISSUE: weak validator: definition inconsistent

If we change the definition "Good enough" should be qualified whether  
the spec means good enough for read-only caching, or good enough for  
write-without-lost-update.

Are there servers that use weak validators besides Apache?

Should Apache's trick of switching from a weak to a strong validator  
(with the ability to compare the strong to the weak) be documented?

Lisa

On Jan 2, 2008, at 1:11 PM, Larry Masinter wrote:

>
> 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 Monday, 7 January 2008 21:42:02 UTC