I'm quite happy for the subject matter experts to decide between
these two approaches.
Thanks
Brian
On 2009-11-27 01:46, Julian Reschke wrote:
Roy T. Fielding wrote:
On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote:
These are the sort of changes that would, I believe, give
sufficient indication to a would-be user of PATCH of how
to make it somewhat safe. Personally I'd prefer to see it
made more prominent by starting with something like:
Clients requiring to verify the consistent application of a
patch document to a known entity SHOULD first acquire an ETag...
Rationale: the use of a normative keyword will draw the
attention of implementors who might otherwise not think
about this issue.
It would also be wrong, because it is neither a requirement
for interoperation nor a potential for causing harm (RFC 2119).
Aside from which, it makes the original purpose of PATCH
non-compliant with its own specification.
The purpose of PATCH is to request that the server apply a
set of changes to the current state of the target resource.
The assumption that these changes will be dependent on a
specific prior representation of that resource is false.
The server is fully capable of detecting and reporting
conflicts when they occur with the current state, as only
truly known by the server.
In other words ...
If the client wants to prevent the PATCH method from being
applied to a resource for which the state has changed since
the last state known by the client, then it SHOULD use one
or more of the conditional request mechanisms of HTTP
(If-Match and If-Unmodified-Since request headers [RFC2616])
or WebDAV (If request header [RFC4918]) with the
associated metadata from that prior resource state.
However, if the patch media type contains its own mechanism
for detecting conflicts, such as embedded context or metadata
designed to allow non-overlapping changes to be safely applied,
then the conditional request mechanisms SHOULD NOT
be used with PATCH because they would interfere with
collaborative applications, such as shared editors and
whiteboards.
FTR, the prior sentence, that PATCH is somehow more likely
to result in corrupted state than a PUT, is simply false for
any patch format that contains context or post-application
integrity checks. The only reason it was in the spec is
because earlier versions assumed a patch format that contains
nothing but byte-vector manipulations. It should be removed,
or at least altered to be factual.
....Roy
In the meantime, a new draft was published, see
<http://tools.ietf.org/html/draft-dusseault-http-patch-16> and
<http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-16.txt>
for the diffs.
The new text is:
A PATCH request can be issued in such a way as to be idempotent,
which also helps prevent bad outcomes from collisions between two
PATCH requests on the same resource in a similar timeframe.
Collisions from multiple PATCH requests may be more dangerous than
PUT collisions, because some patch formats need to operate from a
known base point or else corrupt the resource. Clients using this
kind of patch application SHOULD acquire a strong ETag [RFC2616] for
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.
This text is still problematic, in that
1) It suggests that the client is in control of the etag ("...acquiere a
strong etag..."); however, the client has no control over this at all;
it's the server who decides, and also it's the server who's in charge in
deciding what type of etags it accepts in which operations.
2) It doesn't mention that WebDAV defines another conditional header
which doesn't have the limitations of If-Match (per RFC2616, not HTTPbis).
I found Roy's proposal both easy to understand and correct, and like to
see it (or something more similar to it than the current text) being used.
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf