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

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

> Lisa Dusseault schrieb:
>>> 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.
>
> Yes, but if the server *doesn't* return an ETag (as mandated by  
> CalDAV), it simply uses the Last-Modified time stamp again. That  
> is, it doesn't work at all with servers rewriting the content upon  
> PUT, no matter whether they return an ETag or not.

True.  We agree on the facts :)  To me, the implication is that a  
server that rewrote content would behave best with the Xythos client  
if it issued one ETag on PUT, then another ETag on server-rewrite.   
Then the server-rewrite behaves just like a client-rewrite and the  
Xythos client will eventually download the new content.


>
>>>> 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.
>
> That's certainly one way to do that, but wouldn't issueing the  
> second etag (E2) be pointless in this case?

E2 must be issued because the server can't reuse E1 when it responds  
with 200 OK.  E2 must be different from E1 to comply with spec  
requirements; E3 must be different than E2 (and than E1) so that the  
client synchronizes the rewrite changes.

For a non-XCAP server, E2 isn't strictly necessary (though last- 
modified tricks might be necessary if the server returns no ETag).   
But for an XCAP server requiring a Etag on a 200 OK response to a  
PUT, E2 is necessary to comply with the spec requirements.


Lisa

Received on Wednesday, 13 September 2006 17:28:21 UTC