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