RFC Errata
Found 3 records.
Status: Verified (2)
RFC 5789, "PATCH Method for HTTP", March 2010
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 3169
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Nottingham
Date Reported: 2012-03-28
Verifier Name: Pete Resnick
Date Verified: 2012-03-29
Section 2 says:
If the operation does not modify the resource identified by the Request- URI in a predictable way, POST should be considered instead of PATCH or PUT.
It should say:
If the operation does not modify the resource identified by the Request- URI in a predictable way that's defined by the semantics of the PATCH media type, POST should be considered instead of PATCH or PUT. [Also, I suggest adding this to section two, after the sixth paragraph:] The means of applying a PATCH request to a resource's state is determined by the request's media type. If a server receives a PATCH request with a media type whose specification does not define semantics specific to PATCH, the server SHOULD reject the request by returning the 415 Unsupported Media Type status code, unless a more specific error status code takes priority. In particular, servers SHOULD NOT assume PATCH semantics for generic media types that don't define them, such as "application/xml" or "application/json". Doing so will cause interoperability issues, because the semantics of PATCH become specific to that resource, rather than general.
Notes:
RFC5789 does not explicitly tie PATCHing semantics to the media type of the request. This was well understood in the discussions around the document, and can be read between the lines in it, but it doesn't come out and say it.
Errata ID: 5521
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Nottingham
Date Reported: 2018-10-12
Verifier Name: Barry Leiba
Date Verified: 2020-01-07
Section 2.1 says:
Successful PATCH response to existing text file: HTTP/1.1 204 No Content Content-Location: /file.txt ETag: "e0023aa4f" The 204 response code is used because the response does not carry a message body (which a response with the 200 code would have). Note that other success codes could be used as well. Furthermore, the ETag response header field contains the ETag for the entity created by applying the PATCH, available at http://www.example.com/file.txt, as indicated by the Content-Location response header field.
It should say:
Successful PATCH response to existing text file: HTTP/1.1 204 No Content ETag: "e0023aa4f" The 204 response code is used because the response does not carry a message body (which a response with the 200 code would have). Note that other success codes could be used as well. Furthermore, the ETag response header field contains the ETag for the entity created by applying the PATCH.
Notes:
See discussion at:
https://github.com/httpwg/http-core/issues/20
Status: Reported (1)
RFC 5789, "PATCH Method for HTTP", March 2010
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 7513
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ivan Ivković
Date Reported: 2023-05-09
Section 2 says:
PATCH is neither safe nor idempotent as defined by [<a href="./rfc2616" title=""Hypertext Transfer Protocol -- HTTP/1.1"">RFC2616</a>], <a href="#section-9.1">Section</a> <a href="#section-9.1">9.1</a>.
It should say:
PATCH is neither safe nor idempotent as defined by [<a href="./rfc2616" title=""Hypertext Transfer Protocol -- HTTP/1.1"">RFC2616</a>], <a href="./rfc2616#section-9.1">Section</a> <a href="./rfc2616#section-9.1">9.1</a>.
Notes:
Having a link to #section-9.1 leads the browser to section 9.1 in the current RFC (5789). The link should, however, point to section 9.1 in RFC 2616.