Re: Summary of ETag related issues in RFC2518bis

I agree that returning a 205 is a good way to signal this.

But I also maintain that returning a 205 *and* returning an
ETAG for the PUT content is even better, since existing clients
that use If-Match and If-None-Match (and don't know about the
new 205 convention) will work properly.

Was there some reason why you thought returning a 205 and
not returning an ETAG was preferable?

Cheers,
Geoff

Stefan Eissing <stefan.eissing@greenbytes.de> wrote on 12/21/2005 06:11:45 
AM:

> 
> 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