Re: NEW ISSUE: weak validator: definition inconsistent

Larry, thank you for your insight. I actually reread 2616 and noticed 
that the weak etag concept limits itself to non-subrange GET(/HEAD)
requests in Section 13.3.3 ("Clients MAY issue simple ..."). It's a 
little subliminal there, but supported by Section 3.11 ("A weak entity 
tag can only be used for weak comparison.") together with Section 14.26 
("The weak comparison function can only be used with GET or HEAD 
requests.").

I suggest refrasing

   Clients MAY issue simple (non-subrange) GET requests with either weak
   validators or strong validators. Clients MUST NOT use weak validators
   in other forms of request.

to

   Clients MAY issue simple (non-subrange) GET requests with either weak
   validators or strong validators. Clients MUST NOT use weak validators 
   with requests other than non-subrange GET or HEAD.


But RFC 2616 still has an issue with mixing two concepts under one name. 
Being "weak validator":
-weak etags standing for semantic equivalence and
-weak Last-Modified times standing for possibly two completely different 
 objects

That brings a lot of confusion, especially when almost consolidating 
weak Last-Modified times with semantic equivalence in Section 13.3.3:

      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.

I suggest writing insted

      An entity's modification time, ..., could _not_ be a _strong_ 
      validator, since ...

or adding

      ... But as the same modification time does not guarantee general 
      semantic equivalence, it is likely not even useful for a weak etag 
      at all.


I even suggest splitting up the term "weak validator" by:
-replacing it with "weak Last-Modified time" and "semantic etag"
 (native speakers feel free to propose other synonyms for these two)
-stressing that the use of _weak_ Last-Modified times is for HTTP/1.0 
 compatibility only (isn't it more or less?) and maybe discourage it 
 because of their non-secure nature (could falsely equal two different 
 objects)
 Note: see second part of 13.3.3 on how to deduce Last-Mod to be strong
-making sure everybody understands that there was no intention to 
 allow "unsure etags" in the sense of "weak Last-Modified time"
-correct some occurrence of "weak validator" in the spec where actually 
 meaning "semantic etag" only (and to not include weak Last-Modified 
 times)

This would finally rule out the erroneous use of one-second resolution 
modification times for generating any weak etags (in case of mod time 
being the same second as "now"), if the server doing so does not stand 
up for semantic equivalence of modifications on the same second.

[The server should at most generate a (weak) Last-Modified header or 
provide an ETag based on a secure content hash. I think the server would 
be better off providing no validators at all when the modification time 
can not be distinguished from "now". It could provide strong 
Last-Modified headers and modification time based strong ETags following 
these rules.]



Did I see it right now? (-:

Robert

Received on Monday, 14 January 2008 20:51:23 UTC