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

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.

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

Well, I was trying to avoid a situation where the extensions tries to be 
all for everybody, resulting in something nobody agrees to and 
implements. The draft as current (01) just provides a flag (rewritten or 
not), but of course it could be extended with other information.

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

The problem here is the definition of "semantic effect". It all depends 
on the client. An XCAP client will not consider XML reformatting to be 
important, as long as the Infoset is preserved. A 
WebDAV-to-filesystem-mapper may be concerned by any kind of changes.


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

Any kind of content rewriting is possible. It's hard to predict what 
customers actually use, but I know that at least a virus checker ships 
with the product.

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

Best regards, Julian

Received on Wednesday, 13 September 2006 16:58:05 UTC