Re: NEW ISSUE: weak validator: definition inconsistent

This is now <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/101>.

I've recorded Larry's suggestion as a proposal in the list.


On 30/12/2007, at 3:57 AM, Werner Baumann wrote:

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


--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 28 February 2008 00:19:53 UTC