W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: Summary of ETag related issues in RFC2518bis

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 20 Dec 2005 11:11:12 +0100
Message-Id: <bd8c1ab99eef6cf93729f7121711321c@greenbytes.de>
Cc: w3c-dist-auth@w3.org, Dan Brotsky <dbrotsky@adobe.com>, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
To: Julian Reschke <julian.reschke@gmx.de>


Am 20.12.2005 um 10:17 schrieb Julian Reschke:

>
> Dan Brotsky wrote:
>> ...
>> In no case does a client ever assume that "the text it sent with the 
>> PUT
>> is what would be retrieved by the GET."  That's not what the etag is
>> for.  The etag is to reassure the client that the value on the server
>> *has not changed since the PUT completed*.  No guarantees are issued
>> that the value doesn't change as part of the PUT; that would be a part
>> of the PUT semantics for that server and are outside the scope of
>> WebDAV.
>> ...
>
> Thanks, Dan :-)

Yes.
>
> So let's look at what clients are interested in again:
>
> - they want to avoid fetching an ETag after PUT,

In my thinking, there is no such thing as an ETAG for the PUT body. For 
the HTTP client, the server's storage mechanism is a black box. With 
PUT it can insert bits into that box. With GET it gets bits out of that 
box. The internal wheels and springs of that box is not to be known by 
the client.

IFF a HTTP server sends an ETAG in the repsonse 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.

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.

//Stefan
Received on Tuesday, 20 December 2005 10:11:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:12 GMT