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

On Sep 12, 2006, at 5:05 PM, Jamie Lokier wrote:

>
>    2. If a client receives a strong Etag in a PUT response, it should
>       ignore it.
>
> If there are already deployed clients which don't satisfy requirement
> 2, then it would be appropriate to insist on requirement 1 in future
> specifications, so that future deployments interoperate with existing
> ones.

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.

Throughout 1999 to 2005, the WebDAV and HTTP community tended to  
encourage this kind of implementation. This W3C Note certainly does:  
http://www.w3.org/1999/04/Editing/


>
> If there are already deployed servers which don't satisfy requirement
> 1, then it would be appropriate to insist on requirement 2 in future
> specifications, so that future deployments interoperate with existing
> ones.

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

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.

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

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

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.

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.

>
> But if there are _both_ deployed clients and servers which don't
> satisfy those requirements out there, those will already fail to
> interoperate with each other.  There is no specification which can fix
> this.  However, the choice of 1, 2 or both will affect
> interoperability of future deployments with the existing one.
>

Yes, this is a good analysis.  I know there are significant client  
deployments based on assuming no server-rewriting.  I am not aware of  
server deployments that do rewriting and return strong ETags.  I'm  
thus quite confident about where the interop advantage lies.

Lisa