Re: Summary of ETag related issues in RFC2518bis

Am 20.12.2005 um 21:42 schrieb Geoffrey M Clemm:
> Stefan Eissing <stefan.eissing@greenbytes.de> wrote on 12/20/2005 
> 11:58:01 AM:
>  > 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?

I was looking for a way to tell the client that it has to refetch the 
content. If the server just answers with a temp ETAG, the client will 
find out on the next PUT that "someone" changed the content and 
probably needs to ask its user what to do about it.

Yves proposed 205 answer however sounds like a much better approach.

//Stefan

Received on Wednesday, 21 December 2005 11:13:22 UTC