RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (2)

RFC 5789, "PATCH Method for HTTP", March 2010

Source of RFC: IETF - NON WORKING GROUP
Area 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 GROUP
Area 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="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">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="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">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.

Status: Rejected (1)

RFC 5789, "PATCH Method for HTTP", March 2010

Source of RFC: IETF - NON WORKING GROUP
Area 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.

Report New Errata



Advanced Search