Re: Summary of ETag related issues in RFC2518bis

Stefan Eissing <stefan.eissing@greenbytes.de> wrote on 12/20/2005 11:58:01 
AM:

>    b) GET(PUT(edit(x,z)) != GET(PUT(edit(GET(PUT(x)),z))
>       In this case the server modifies the content of a PUT in a way 
> which somewhat random or for example counting the number of 
> modifications inside the content.
> 
> Case b) seems to be what you mean with "substantive" changes. My 
> interpretation would be that the server shall either be silent with 
> regards to ETAG on the PUT response. And that a client which does not 
> see an ETAG in a PUT response, should make a GET afterwards. If it 
> wants to avoid concurrent updates, it could lock the resource just for 
> the PUT with subsequent GET.

If the server includes the etag corresponding to the PUT content, 
standard If-Match and If-None-Match processing works properly. 
Isn't supporting the standard semantics better than hoping clients will
interpret the absence of an etag header in a certain way? 

Cheers,
Geoff