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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf