Subject: Re: NEW ISSUE: weak validator: definition inconsistent

From: "Larry Masinter" <[email-masked]>
Date: Sun, 13 Jan 2008 08:11:56 -0800

I think people are imagining uses for eTags that they weren't designed for,
don't work for, and are inconsistent with the original intent and design.
When we were working on the cache validation part of the HTTP specification,
there were a lot of design choices - were the entity tags globally unique or
just unique for the URL, who could set an entity tag, etc.

After considering a lot of alternatives and came down to the point (perhaps
argued most cogently by Jeff Mogul) that for the main purpose of entity
tags, which was to improve web performance by enabling proxy caching of GET
requests, we should put the fewest constraints on server implementations to
allow for the most flexibility, even at the expense of not supporting other
applications of content identification which might be supported by changing
entity tags. 

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

If we follow the original "spirit" (or at least intent): "good enough" means
"whatever the server thinks is good enough".  The server is in control.  If
the server wants to allow lost updates, the server  is free to lose updates.
You're asking for a service guarantee in the protocol, and you won't get
one. If you don't like the server's policy, use a different server. 

  "-servers can't "automatically" generate weak etags for e.g. files, as
they have no idea about semantic equivalence"
 
This is an unacceptable change. Servers are in control of what the server
considers to be semantic equivalence. If the client has a different idea,
then too bad: etags don't help. 
 
"-if a client provides a weak etag or downgraded a strong etag to a weak "
 
I think this is a false premise: clients don't provide etags, servers do.
Clients may return an etag, but shouldn't be downgrading or modifying it in
any way.
 
-range and range-like requests form no exception: if the range is octet 
 based, the client should not put weak etags in requests if it has no
 means of combining weak match results (it may have ways to do so, with 
 overlapping parts or such things...)
 
Range requests only make sense with strong validators.  In fact, the main
reason for adding strong validators and not just weak validators was so the
clients could know whether they could use range request.
 
Larry

---

From: Robert Siemer <[email-masked]>
Date: Mon, 14 Jan 2008 21:52:10 +0100

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