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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
