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

On Sep 13, 2006, at 9:09 AM, Julian Reschke wrote:

> 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  
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/ 
> 0090.html>).

I can't really see how we disagree here.  If the server returns a  
strong ETag, the Xythos client assumes that the content was written  
as sent.  Later, when the client attempts to refresh its cache, if  
the ETag is still the same, the client happily continues using the  
entity that it PUT.   Thus, a user can refresh and refresh and  
refresh, and still not see quite what the server has stored and other  
clients/users see.

With some kinds of modifications that may be important, in some cases  
it may be annoying, in some cases it might be all-but-indetectable.   
But I worry about an approach that handles that whole scale of  
modifications the same way and leaves existing deployed clients  
ignorant of all such changes.

I guess it might be reasonable to slice and dice.
  - For changes that really have no semantic effect  (like XML re- 
formatting) it would be OK for a server to behave as described in  
your draft.
  - For changes that have even small semantic effects (like variable  
replacement), it's very useful to notify existing clients of the  
change in such a way that the cached content eventually gets updated  
and the user sees what other users see.
  - For changes that have larger semantic effect or aren't  
repeatable, we do move to the "lost-update" problem and I believe we  
agree on the best course there.

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

I agree, or to say again, I can't really see that we disagree here.   
If the server is making modifications that can be repeated  
successfully, there isn't a lost-update problem.  There may be an  
annoyed user 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 ETags).

What kind of content-rewriting?  On what kind of resources?  Would a  
GIF be allowed and possibly modified?  A Word document?  Does the  
product ship this way or is it that customer modifications could  
result in a service instance that did content rewriting?


>
>> 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 point?

The 3rd ETag is needed if the kind of change the server made might  
possibly be of any use to the user.  The 3rd Etag means that if the  
client refreshes its offline cache, the server change is downloaded.   
For simple XML spacing changes, that might not be any use.  For any  
semantic change, even if it's the kind that can be repeated for any  
future update (similar to CVS variable replacement), the 3rd ETag  
means that the user will see the content as its seen by others.

thanks,
Lisa