Re: NEW ISSUE: weak validator: definition inconsistent

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