Re: i22: ETags on PUT responses

On lör, 2008-01-05 at 22:55 +0100, Werner Baumann wrote:

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

I don't agree here. Why do you see this as such big problem?

I am missing a usecase where this really causes a problem. All I see is
plenty of usecases there not sending the ETag would be a major problem.

The use of the ETag returned by PUT is to know that the resource has not
been changed after the PUT request completed. Not that there is
octet-equality between what the client sent and what got stored on the
server.

This ETag is useful for pretty much all operations except ranged
retreival (which is in itself useless here if the client already has the
object). And very useful for subsequent PUT/DELETE requests to avoid the
lost update problem.

The fact that the server issues some kind of transform of the PUT
content is generally not such big deal. Sure, it means the client would
not get the same representation if it issues a GET, but the
representation the client sent is still good enough and SHOULD result in
a at least semanticaly equivalent entity if the PUT is repeated.

It's not a problem for subsequent PUT requests from the same client. The
server SHOULD apply the same kind of transform on those, ending up in
the same result even if the client has not refetched the object before
the next update.

It's certainly not a problem for DELETE.

Regards
Henrik