RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app
See Also: RFC 5789 w/ inline errata

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.

Report New Errata



Advanced Search