Re: Etag-on-write, 2nd attempt (== IETF draft 01)

Lisa Dusseault schrieb:
> Yes, that's exactly it -- Xythos WebFile Client behaved this way, and 
> based on their user-facing behavior I suspect many others do too 
> although I can't test them right now.  I'm thinking particularly synch 
> tools like 'sitecopy', but possibly also networked share viewers like 
> WebDAV-FS on Mac and the Windows clients.  

That's incorrect, at least as the Xythos client is concerned (see 

> Throughout 1999 to 2005, the WebDAV and HTTP community tended to 
> encourage this kind of implementation. This W3C Note certainly 
> does:

I'm really not sure how this is relevant for the discussion. It's 
perfectly OK for a client to use continue editing using an ETag obtained 
from PUT, even if the server rewrote the content. Saving the modified 
content again will just cause the content to be rewritten again. This is 
not a case of a "lost update" problem.

> We are starting to envision such servers, but I don't know that they're 
> deployed yet, and certainly not for the general case.  It's particularly 

They are, and have been around for quite some time (SAP's KM allows 
content rewriting upon PUT, in which case it will still return strong 

> for the case of servers specialized to store certain formats, like 
> calendar data or XML data, that this type of behavior may in the future 
> become implemented/deployed.   

Other use cases are filtering and keyword expansion.

> The two special cases I'm aware of are CalDAV and XCAP: both store a 
> specialized format and a certain kind of data, understand the data at a 
> semantic level, and a server could conceivably be "extra helpful" and 
> add data to those resources.  

AtomPub as well.

>  * For CalDAV, we proposed that if a server adds information to a 
> resource upon write, it not return a strong ETag, and thus work with 
> existing clients. 

It would be nice if you could provide evidence of clients (written prior 
to the text in the CalDAV spec) that make this assumption.

>  * XCAP says in 7.11:
>    When a client uses conditional PUT and DELETE operations, it can
>    apply those changes to its local cached copy, and update the value of
>    the entity tag for the locally cached copy based on the Etag header
>    field returned in the response.  As long as no other clients try to
>    modify the document, the client will be able to perform conditional
>    operations on the document without ever having to perform separate
>    GET operations to synchronize the document and it's entity tags with
>    the server. 

Yes. Note that this works even though XCAP servers usually will reformat 
the XML, as long as no byte-range requests are made.

> Note that XCAP also says in 8.5 that the server MUST return the ETag 
> header in all 200 or 201 responses to PUT.  To me, combining these 
> statements means that there's only one way a server could make 
> modifications to a resource on write:
> Start with a resource with ETag value E1.
> Accept the PUT request and return a strong ETag as required.  It must be 
> a new value, lets say E2. 
> Perform its modification and change the resource ETag to another new 
> value, say E3.
> With this approach, an XCAP server could literally meet the requirement 
> to return the ETag header, yet also force clients that are written to 
> work as described in 7.11 to get the correct resource version.  

I'm not sure why a third ETag is needed. Could you please clarify that 

> JDR may be able to clarify what the common assumption is for XCAP -- 
> perhaps it's that servers *not* modify resources.
> Anyway, leaving the special cases again, I am not aware of any general 
> WebDAV servers -- servers which accept general content just like a file 
> server would -- which make modifications before returning a strong ETag.

Well, I am (see previous mail for details).

Best regards, Julian

Received on Wednesday, 13 September 2006 16:09:10 UTC