Re: i22: ETags on PUT responses

Werner Baumann wrote:
> 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.

I'm not sure I understand; maybe you could be more specific. The 
examples I'm giving are all allowed by what RFC2616 says.

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

Yes, but when they start making conflicting requirements (and they do), 
writing generic clients/libraries/middleware/intermediates becomes 
problematic.

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

My understanding is that your proposal changes the semantics of RFC2616, 
  breaks existing servers, and rules out lots of applications what work 
fine today.

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

That is incorrect (really!). There are many examples where servers do 
not store the content octet-by-octet, but strong ETags just work fine.

You seem to argue from the POV of a WebDAV client implementor. There's 
nothing wrong with that, but filesystem-semantics-over-HTTP is just one 
out of many use cases.

> ...

Best regards, Julian

Received on Sunday, 6 January 2008 16:34:09 UTC