RE: Summary of ETag related issues in RFC2518bis

Ah, now I begin to understand what I believe is a big misimpression on
the part of the server authors.  (Sadly, I see almost no client authors
in these discussions anymore, which has been a big part of my problem
with the WebDAV process forever and why I've been quiet for so long
now.)
 
Folks, clients are perfectly well aware that servers munge data when
they store it.  It's *way* outside the scope of WebDAV to try and match
up the server-munging semantics with clients that rely on those
semantics.  If you are a client that's looking for a faithful dumb store
and you stumble across a CVS-backed webdav server that does keyword
expansion to your graphics files, you will figure this out quickly and
stop using that server.  That doesn't mean it's not a WebDAV-compliant
server, just not one with the store semantics you were expecting.
 
Similarly, if you are a client expecting a CVS server and you use a
file-backed Apache server, it also won't meet your needs.  But it's
still WebDAV-compliant.
 
The point of this effort is to define a greatest common denominator that
can be divided evenly into the semantics of any server that's called
WebDAV compliant.  But believe me, every client in the world understands
that there may be extra factors in that server's semantics that are
relatively prime with the client's intent!
 
That's a good thing.
 
    dan


________________________________

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

	"Dan Brotsky" <dbrotsky@adobe.com> wrote on 12/20/2005 12:09:21
AM:
	
	> In no case does a client ever assume that "the text it sent
with the PUT
	> is what would be retrieved by the GET." 
	
	I agree. 
	
	> That's not what the etag is for. 
	
	That is what is up for debate.  If a server has modified the
text in a 
	way that the user needs to see (i.e., the modified text needs to
be 
	the basis for subsequent edits), then there needs to be an
efficient way 
	for the client to find this out. 
	
	One technique would be to define the etag returned by the PUT as

	being the etag corresponding to PUT text.  Then if a client
wants to perform 
	further edits on that text, it should issue a GET with an
If-None-Match 
	header containing that etag.  If new text is returned, then it
should 
	base its edits on that new text.  If no new text is returned, it
knows 
	it can continue editing the text that was submitted earlier with
the PUT. 
	
	> The etag is to reassure the client that the value on the
server
	> *has not changed since the PUT completed*. 
	
	How is that sufficient?  If the changes made by the server are 
	substantive (and should be the basis for subsequent edits),
returning 
	the etag that corresponds to the text on the server will mislead
the 
	client into thinking it can make changes to the text it sent up
with 
	the PUT, when in fact it should download the server text with a
GET first. 
	
	Cheers,
	Geoff