Re: Summary of ETag related issues in RFC2518bis

Am 20.12.2005 um 16:45 schrieb Geoffrey M Clemm:
> Stefan wrote on 12/20/2005 05:11:12 AM:
>
>  > IFF a HTTP server sends an ETAG in the response to a PUT, the 
> contract
>  > should be as follows:
>  >     The PUT bits changed the state of the resource to something 
> where at
>  > least one varient of carries the following ETAG. If you make a
>  > subsequent PUT with this ETAG in an IF-* header, your PUT is likely 
> to
>  > succeed during normal operations. Or the other way round: if any 
> agent
>  > subsequently modifies the resource, the ETAG will change.
>
> What about the situation where the server itself is the "agent that
> modified the resource" (and did so during the PUT)?  If this 
> modification
> is substantive, the client cares both for GET (to see what is currently
> on the server) and for PUT (to base subsequent edits on what is 
> actually
> on the server).

Yes, such servers are imaginable. No, there are not very useful:

Mathematically speaking if PUT(x) is the function in the server that 
takes the client input and modifies it, so that a subsequent 
GET(PUT(x)) defines the content a client gets back. We are talking 
about the situation where    x != GET(PUT(x)) because the other case is 
trivial.

So, the discussion is about: when is it safe for the client to continue 
editing x and when should it really be editing GET(PUT(x)) and what is 
the role of the ETAG in all of this.

So, let edit(x, z) be the content after an edit z of x, then we have 
basically two  cases:

   a) GET(PUT(edit(x,z)) == GET(PUT(edit(GET(PUT(x)),z))
      Read: the result of putting the edit of the original x and the 
putting of the edit of GET(PUT(x)) is the same. Keyword substitutions 
fall in this category. It is safe to submit old values since they are 
always overwritten by the new ones on PUT. Not a problem.

   b) GET(PUT(edit(x,z)) != GET(PUT(edit(GET(PUT(x)),z))
      In this case the server modifies the content of a PUT in a way 
which somewhat random or for example counting the number of 
modifications inside the content.

Case b) seems to be what you mean with "substantive" changes. My 
interpretation would be that the server shall either be silent with 
regards to ETAG on the PUT response. And that a client which does not 
see an ETAG in a PUT response, should make a GET afterwards. If it 
wants to avoid concurrent updates, it could lock the resource just for 
the PUT with subsequent GET.

//Stefan

>  > The last part is important for a WebDAV client, since it wants to 
> use
>  > ETAG for optimistic  locking. It is not really interested in ETAG 
> for
>  > caching purposes.
>
> Actually, I think a WebDAV client cares about both optimistic locking
> and caching.  Also note that they are rather intimately linked, since
> optimistic locking is based on knowing that the client's edits are 
> based on the
> text that is currently on the server, while caching is based on knowing
> that what the client currently has is based on the text that is 
> currently on
> the server.

One Counterexample is Keyword substitution. It is safe to edit and 
submit old substitution values.

Received on Tuesday, 20 December 2005 16:58:19 UTC