Technical Summary
Several applications extending the Hypertext Transfer Protocol (HTTP)
require a feature to do partial resource modification. This proposal
adds a new HTTP method, PATCH, to modify an existing HTTP resource in
a generic way.
Working Group Summary
This is not a Working Group document; rather, it is an Individual
Submission that is seeking IETF Consensus as an Standards Track RFC.
However, this document has been reviewed and discussed extensively
on the HTTPbis, WebDAV and Atom mailing lists.
Document Quality
The document has been reviewed extensively on the HTTPbis mailing
list over a long period of time, and no substantive issues have
arisen in the last few drafts. There has not yet been appreciable
implementation experience, although several vendors have expressed
interest.
Personnel
Mark Nottingham is the Document Shepherd for this document.
Alexey Melnikov is the responsible AD.
RFC Editor Notes
In Section 2, change the last 2 sentences of the 4th paragraph to read:
OLD:
Clients using this
kind of patch application SHOULD acquire a strong ETag [RFC2616] for
the resource to be modified, and use that ETag in the If-Match header
on the PATCH request to verify that the resource is still unchanged.
If a strong ETag is not available for a given resource, the client
can use If-Unmodified-Since as a less-reliable safeguard.
NEW:
Clients using this kind of patch application SHOULD use a conditional
request such that the request will fail if the resource has been
updated since the client last accessed the resource. For example,
the client can use a strong ETag [RFC2616] in an If-Match header
on the PATCH request.
In Section 2.1, change everything starting from the 3rd paragraph:
OLD:
This example illustrates use of a hypothetical patch document on an
existing resource. The 204 response code is used because the
response does not have a body (a response with the 200 code would
have a body) but other success codes can be used if appropriate.
Successful PATCH response to existing text file
HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"
NEW:
This example illustrates use of a hypothetical patch document on an
existing resource.
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.
Futhermore, 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.
Please change the last paragraph of the Section 3.1 to read:
OLD:
The Accept-Patch header specifies a comma separated listing of media-
types as defined by [RFC2616], Section 3.7.
NEW:
The Accept-Patch header specifies a comma separated listing of media-
types (with optional parameters) as defined by [RFC2616], Section 3.7.
Example:
Accept-Patch: text/example;charset=utf-8