--On Tuesday, November 17, 2009 15:27 +0100 Julian Reschke <julian.reschke@xxxxxx> wrote: > 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#sect > ion-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? Largely, yes, as long as the other changes you list below are addressed (comments below). > 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 Silent, no. But saying "can't control... certain instances" explicitly would be fine. I'd be even happier with an explanation of what such an instance might look like, but don't see that as a requirement. > 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 yes > 3) Get rid of the text that suggests that a last modified date > somehow is better than a weak etag. Probably a good idea. john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf