Re: Summary of ETag related issues in RFC2518bis

Stefan wrote on 12/20/2005 05:11:12 AM:

> IFF a HTTP server sends an ETAG in the response to a PUT, the contract 
> should be as follows:
>     The PUT bits changed the state of the resource to something where at 

> least one varient of carries the following ETAG. If you make a 
> subsequent PUT with this ETAG in an IF-* header, your PUT is likely to 
> succeed during normal operations. Or the other way round: if any agent 
> subsequently modifies the resource, the ETAG will change.

What about the situation where the server itself is the "agent that
modified the resource" (and did so during the PUT)?  If this modification
is substantive, the client cares both for GET (to see what is currently
on the server) and for PUT (to base subsequent edits on what is actually
on the server). 

> The last part is important for a WebDAV client, since it wants to use 
> ETAG for optimistic  locking. It is not really interested in ETAG for 
> caching purposes.

Actually, I think a WebDAV client cares about both optimistic locking
and caching.  Also note that they are rather intimately linked, since
optimistic locking is based on knowing that the client's edits are based 
on the
text that is currently on the server, while caching is based on knowing
that what the client currently has is based on the text that is currently 
on
the server.

Cheers,
Geoff