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

Re: Summary of ETag related issues in RFC2518bis

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Tue, 20 Dec 2005 15:20:36 -0500
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OF5528BD5E.3D6461AF-ON852570DD.006E354D-852570DD.006FC025@us.ibm.com>
Lisa Dusseault <lisa@osafoundation.org> wrote on 12/20/2005 01:01:22 PM:

> ... if in 
> some cases the server needs the client to do a GET between two 
> subsequent PUTs because the changes are important to preserve, how can 
> the server accomplish that?
> I believe there is a way without any additional mechanisms:
>   - If the server is making changes that can be overwritten without 
> harm, or if the server is making no changes, it can return an ETag in 
> response to PUT and the client doesn't have to do a GET unless it later 
> sees a different ETag.
>   - If the server is making changes that must be preserved, then the 
> server can respond to the initial PUT with a throwaway ETag, then 
> immediately update the ETag of the resource to a new and more permanent 
> value.  Now the client will be forced to recognize that there are new 
> changes to be synched -- just as if another client had made the change 
> in that period of time.

I'd word it somewhat differently, but this is basically what I meant by
saying that "the etag should correspond to the content specified for the 
If the content specified by the PUT is equivalent to what will be 
by a GET, then the PUT etag will match the GET etag.  If the content 
by the PUT is not equivalent to what will be retrieved by a GET (the 
case), I wouldn't call this a "throwaway" etag, but 

> Most clients would already be compliant with this.

Yes, that is why I prefer this interpretation.

> If we decided to make this kind of recommendation, we'd also have to 
> specify whether it's OK to do this while the client is holding a LOCK.

I think it is clear that the answer to this should be "yes", but stating 
explicitly is fine with me.

Received on Tuesday, 20 December 2005 20:20:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC