weak etags vs PATCH, was: Fwd: New Version Notification - draft-dusseault-http-patch-15.txt

Mark Nottingham wrote:
>>
>>
>> New version (-15) has been submitted for 
>> draft-dusseault-http-patch-15.txt.
>> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.txt
>> Sub state has been changed to AD Follow up from New Id Needed
>>
>> Diff from previous version:
>> http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-15
>>
>> IETF Secretariat.
> 
> 
> -- 
> Mark Nottingham     http://www.mnot.net/

Looks good to me, except for one thing I mentioned before (see, for 
instance, 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0174.html>):

>    Collisions from multiple PATCH requests are more dangerous than PUT
>    collisions, because a patch document that is not operating from a
>    known base point may corrupt the resource.  Clients wishing to apply
>    a patch document to a known entity can first acquire the strong ETag
>    [RFC2616] of the resource to be modified, and use that Etag in the
>    If-Match header on the PATCH request to verify that the resource is
>    still unchanged.  If a strong ETag is not available for a given
>    resource, the client can use If-Unmodified-Since as a less-reliable
>    safeguard.

Recommending the use of timestamps instead a potentially available weak 
etag simple does not make sense. After all, the server is minting the 
etags, and it also controls what it accepts in conditional PATCH 
requests. Let it decide what's right.

BR, Julian

Received on Friday, 16 October 2009 11:34:40 UTC