W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: Summary of ETag related issues in RFC2518bis

From: Yves Lafon <ylafon@w3.org>
Date: Tue, 20 Dec 2005 18:17:11 +0100 (MET)
To: Stefan Eissing <stefan.eissing@greenbytes.de>
cc: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, webdav <w3c-dist-auth@w3.org>
Message-ID: <Pine.GSO.4.64.0512201808040.12809@gnenaghyn.vaevn.se>

On Tue, 20 Dec 2005, Stefan Eissing wrote:

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

If the server marginally modified the resource (like adding a cvs commit
timestamp), editing the current "x" copy should not generate errors (case 
If changes may be more drastic in the document after the PUT so that
continuing to edit "x" client side is an issue, then it would be safe for
the server to reply to the PUT(x) with the HTTP status code 205 (Reset
Content), even if "The server has fulfilled the request and the user agent
SHOULD reset the document view which caused the request to be sent." could
be clarified in this case as "the client should issue a GET to retreive
the latest version fo the document to edit"

In any case, I don't see what's preventing the server to generate the ETag 
of the document you might get... with a GET (so, not the ETag of what has 
been put)

Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Tuesday, 20 December 2005 17:22:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC