Re: i22: ETags on PUT responses

Henrik Nordström wrote:
> > 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.
> 
> PUT is also in this category, same as DELETE. The transform applied by
> the server on the stored resource MUST be repeatable and not dependent
> on seeing that transform in future PUTs to the same resource.
> 
> This comes from partially the fact that PUT is a non-indempotent
> request, just as GET/DELETE. There must be no harm done on the server by
> repeating the same PUT.

I think you meant "PUT is idempotent, just as GET/DELETE".

Idempotence doesn't imply the byte transformation is repeated exactly.

For example, it's perfectly reasonable for the server to replace each
occurence of "$PUT-Date$" in the entity with the actual date when it
received the entity.  That needn't be byte identical between requests,
but also it doesn't cause any harm if the PUT is repeated.

It's not even detectable by the client which repeated the PUT request,
assuming it didn't do any other operations in between.  (And RFC2616
notes that idempotence isn't expected when an operation is repeated
with others in between).

-- Jamie

Received on Monday, 7 January 2008 13:23:33 UTC