Re: Last Call: draft-dusseault-http-patch (PATCH Method for HTTP) to Proposed Standard

[Julian Reschke <julian.reschke at gmx.de>]

The IESG wrote:
> The IESG has received a request from an individual submitter to consider 
> the following document:
>
> - 'PATCH Method for HTTP '
>    <draft-dusseault-http-patch-15.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf at ietf.org mailing lists by 2009-11-24. Exceptionally, 
> comments may be sent to iesg at ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> ...

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> 
and again in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009OctDec/0112.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.

(This issue was pointed out previously; note that HTTPbis already allows 
weak etags in write operations, and WebDAV has allowed weak etags in the 
"If" header since its inception).


BR, Julian