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@xxxxxxxx mailing lists by 2009-11-24. Exceptionally,
comments may be sent to iesg@xxxxxxxx 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
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf