RE: Summary of ETag related issues in RFC2518bis

I agree that there may be a big misimpression on the part of server
authors (but probably we differ on who we think those server authors
are :-).

In particular, I don't think anyone is suggesting/expecting that
we match up server munging semantics ... all that some of us
are suggesting/expecting is that there be a well-defined way in
which a server can let a client know that it has significantly modified
the submitted text, preferably in a way that will automatically work
for (at least some) existing clients.  That is the reason for
focusing on etags, since an existing client that does an If-Match
or If-None-Match with the etag returned by PUT will work properly
on server-munged content if we return an etag for the PUT content
that is different from the etag for the subsequent GET content.

Using the 205 return code is also desireable, although this would
primarily be for the benefit of future clients, since I doubt many
existing clients have special handling for when 205 is returned by PUT.

Cheers,
Geoff




"Dan Brotsky" <dbrotsky@adobe.com> wrote on 12/21/2005 01:17:16 AM:

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