Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



John C Klensin wrote:
...
Standard etag conflict resolution is not required because
it is not desirable for many applications of PATCH.  For
other applications of PATCH, it is already defined by HTTP
and does not need to be reiterated here.

We disagree.  I believe it does "need to be reiterated here",
either in-line or by an explicit, normative, pointer to the
relevant portion of the HTTP spec.
...

<http://tools.ietf.org/html/draft-dusseault-http-patch-15#section-2> already says:

   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.

So would replacing the 2nd part by:

   Clients wishing to apply a patch to a known entity can first
   acquire an ETag ([RFC2616], Section 3.11) of the entity to be
   modified, and use that ETag to make the PATCH request conditional,
   such as by including the "If-Match" request header field ([RFC2616],
   Section 14.24).

address this concern?

Note that this makes some more changes:

1) the client can't control whether the etag will be strong, and weak etags may work just fine in certain instances, so just be silent about the type

2) speak of "conditional requests" in general, and just mention "If-Match" as one way to get there; there may be other ways such as using the WebDAV "If" header

3) Get rid of the text that suggests that a last modified date somehow is better than a weak etag.

Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]