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