RE: Summary of ETag related issues in RFC2518bis

Geoff, Lisa,
 
Thanks for the clarification.
 
I think cacheing clients such as yours really care whether the server
munges the received content or not.  My perspective is that you need to
actually do a get, then, after your put.  I don't think you should rely
on the received etag;  you will need the MD5 to avoid the get.
 
    dan


________________________________

	From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm
	Sent: Wednesday, December 21, 2005 10:31
	To: webdav
	Subject: RE: Summary of ETag related issues in RFC2518bis
	
	

	"Dan Brotsky" <dbrotsky@adobe.com> wrote on 12/21/2005 01:22:17
AM:
	
	>> I think a WebDAV client cares about both optimistic locking 
	>> and caching.   
	>   
	> I strongly disagree. 
	
	Like Lisa, our client writers care about both optimistic locking

	and caching.  And I don't think we are the only ones that feel
that way. 
	
	>>  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.   
	  
	> No.  Optimistic locking is based on knowing that the client's
edits 
	> are being applied to the content the client last sent to the
server,
	> and are not overwriting other client's edits.  Caching is
based on 
	> knowing that the content you *last received* is the same as
what you
	> *would receive* on your next get. 
	
	Our client writers care about all three, i.e. optimistic locking
(whose 
	definition we appear to agree on), GET caching (i.e., what you
define as 
	caching), and re-use of the content submitted for a PUT
(included in my 
	more general definition of caching). 
	
	> HTTP clients, whether webdav or not, know they must have
*received* 
	> the content associated with an etag in order to avoid fetching
it 
	> again.  That's caching. 
	
	I am happy to use "caching" to only mean "GET caching" 
	if that's what you prefer, but our clients also care about the
more general 
	form of caching that I described, whatever name we use for it. 
	One of the points of this discussion is to determine whether
clients should 
	be able to use etags returned by PUT for this other kind of
caching. 
	
	> WebDAV clients only need to know that they *sent* the content 
	> associated with an etag in order to avoid overwriting someone
else's
	> edits.  That's optimistic locking. 
	
	Our WebDAV clients also care about performance, so they also
care about 
	caching, not just about optimistic locking. 
	
	Cheers, 
	Geoff