Re: Summary of ETag related issues in RFC2518bis

Yves Lafon <ylafon@w3.org> wrote on 12/20/2005 12:17:11 PM:

> If changes may be more drastic in the document after the PUT so that
> continuing to edit "x" client side is an issue, then it would be safe 
for
> the server to reply to the PUT(x) with the HTTP status code 205 (Reset
> Content), even if "The server has fulfilled the request and the user 
agent
> SHOULD reset the document view which caused the request to be sent." 
could
> be clarified in this case as "the client should issue a GET to retreive
> the latest version fo the document to edit"

Making returning a 205 a MUST (or at least a SHOULD) in this case
sounds good to me.

> In any case, I don't see what's preventing the server to generate the 
ETag 
> of the document you might get... with a GET (so, not the ETag of what 
has 
> been put)

A server can of course do what it wants since the spec currently doesn't 
deal
with this issue, but doing so will cause failures in clients that use
a GET with an If-None-Match header with that etag, since the server 
will not return the new content (because the etag matches the server 
value).

Cheers,
Geoff