RFC Errata
RFC 5789, "PATCH Method for HTTP", March 2010
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 3419
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Daniel Hardman
Date Reported: 2012-11-27
Rejected by: Barry Leiba
Date Rejected: 2012-11-27
Section 1 says:
A new method is necessary to improve interoperability and prevent errors. The PUT method is already defined to overwrite a resource with a complete new body, and cannot be reused to do partial changes. Otherwise, proxies and caches, and even clients and servers, may get confused as to the result of the operation.
It should say:
A new method may be desirable (though it is not strictly necessary). The PUT method is already defined to overwrite a resource or a subset thereof (see RFC 2612 section 9.6), but the semantics of Content-Range with PUT have been poorly understood and implemented by the community. To avoid breaking existing proxies and caches that may be confused by PUT with a partial update, PATCH seems like a better solution.
Notes:
Contrary to what is claimed in the justification for this RFC, RFC 2616 clearly
anticipates the possibility of doing PUT with a partial content range. See section
9.6 (http://tools.ietf.org/html/rfc2616#section-9.6). Thus, PUT is the moral
equivalent of fseek() + fwrite(), not just fwrite(). I have personally implemented
web services that use PUT with Content-Range, and I don't think I'm alone. The
fact that the community has not generally understood this nuance does not
necessarily mean PATCH is needed. It would be possible to simply clarify how
PUT is used with Content-Range and accomplish virtually everything that PATCH
is attempting. However, PATCH has the virtue of no semantic baggage, and it may
also be nice to use patch-if logic like the familiar *nix-style patch program, which
is a valid semantic enhancement to dumb update. This point needs to be made
more clearly in the RFC's preamble; as-is, I think the case for PATCH is too weak.
--VERIFIER NOTES--
A disagreement with IETF consensus does not an erratum make. You may have strong disagreement with the document as published, but what's published is what was intended to be published; this is not an "error" in the document.