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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf