--On Tuesday, November 17, 2009 15:27 +0100 Julian Reschke
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.
ion-2> already says:
Collisions from multiple PATCH requests are more dangerous
collisions, because a patch document that is not operating
known base point may corrupt the resource. Clients
wishing to apply
a patch document to a known entity can first acquire the
[RFC2616] of the resource to be modified, and use that
Etag in the
If-Match header on the PATCH request to verify that the
still unchanged. If a strong ETag is not available for a
resource, the client can use If-Unmodified-Since as a
So would replacing the 2nd part by:
Clients wishing to apply a patch to a known entity can
acquire an ETag ([RFC2616], Section 3.11) of the entity to
modified, and use that ETag to make the PATCH request
such as by including the "If-Match" request header field
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
3) Get rid of the text that suggests that a last modified date
somehow is better than a weak etag.
Probably a good idea.
Ietf mailing list