Re: Summary of ETag related issues in RFC2518bis

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 
PUT".
If the content specified by the PUT is equivalent to what will be 
retrieved
by a GET, then the PUT etag will match the GET etag.  If the content 
specified
by the PUT is not equivalent to what will be retrieved by a GET (the 
second 
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 
it
explicitly is fine with me.

Cheers,
Geoff