Re: i22: ETags on PUT responses

Hello Julian,

all your examples rely either on an extension protocol or on some 
out-of-band agreement between server and client. But this is about pure 
HTTP, without extensions and additional agreements.

Extension protocols are free to make their own rules about when it is 
sensible to send an etag and what it can be used for.

My proposal
 > When a server changes the body submitted in the PUT-request, it
 > MUST NOT send an Etag-header in response, unless it knows that
 > the client is aware of this changes and can handle them.
is meant to allow for just this freedom, but to prevent servers without 
this additional knowledge from sending useless etags, what would render 
all etags in PUT-responses useless for many clients. Of course there may 
be a better wording.

The only use case, where a client can make use of the etag without 
further knowledge and guarantee is DELETE. It suffices to know, that the 
resource has not been modified by someone else in between. In all other 
use cases, the client must know, whether there are manipulations by the 
server that might conflict with what the client wants to do.

When server and client share additional information and agreements, they 
are free to do anything and may even ignore the specifications, as long 
as they do not communicate with the world outside.

Werner

Received on Sunday, 6 January 2008 16:21:04 UTC