Internet Engineering Task Force (IETF) L. Dusseault
Request for Comments: 5789 Linden Lab
Category: Standards Track J. Snell
ISSN: 2070-1721 March 2010
Internet Engineering Task Force (IETF) L. Dusseault
Request for Comments: 5789 Linden Lab
Category: Standards Track J. Snell
ISSN: 2070-1721 March 2010
PATCH Method for HTTP
HTTP的补丁方法
Abstract
摘要
Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.
一些扩展超文本传输协议（HTTP）的应用程序需要一个功能来进行部分资源修改。现有的HTTP PUT方法只允许完全替换文档。此建议添加了一个新的HTTP方法PATCH，以修改现有的HTTP资源。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5789.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5789.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. The PATCH Method ................................................2
2.1. A Simple PATCH Example .....................................4
2.2. Error Handling .............................................5
3. Advertising Support in OPTIONS ..................................7
3.1. The Accept-Patch Header ....................................7
3.2. Example OPTIONS Request and Response .......................7
4. IANA Considerations .............................................8
4.1. The Accept-Patch Response Header ...........................8
5. Security Considerations .........................................8
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References .....................................9
Appendix A. Acknowledgements .....................................10
1. Introduction ....................................................2
2. The PATCH Method ................................................2
2.1. A Simple PATCH Example .....................................4
2.2. Error Handling .............................................5
3. Advertising Support in OPTIONS ..................................7
3.1. The Accept-Patch Header ....................................7
3.2. Example OPTIONS Request and Response .......................7
4. IANA Considerations .............................................8
4.1. The Accept-Patch Response Header ...........................8
5. Security Considerations .........................................8
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References .....................................9
Appendix A. Acknowledgements .....................................10
This specification defines the new HTTP/1.1 [RFC2616] method, PATCH, which is used to apply partial modifications to a resource.
本规范定义了新的HTTP/1.1[RFC2616]方法PATCH，用于对资源应用部分修改。
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. POST is already used but without broad interoperability (for one, there is no standard way to discover patch format support). PATCH was mentioned in earlier HTTP specifications, but not completely defined.
需要一种新的方法来提高互操作性和防止错误。PUT方法已定义为用一个完整的新主体覆盖资源，不能重复使用以进行部分更改。否则，代理和缓存，甚至客户端和服务器，可能会对操作结果感到困惑。POST已经被使用，但没有广泛的互操作性（例如，没有发现补丁格式支持的标准方法）。补丁在早期的HTTP规范中提到过，但没有完全定义。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Furthermore, this document uses the ABNF syntax defined in Section 2.1 of [RFC2616].
此外，本文件使用[RFC2616]第2.1节中定义的ABNF语法。
The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request-URI. The set of changes is represented in a format called a "patch document" identified by a media type. If the Request-URI does not point to an existing resource, the server MAY create a new resource, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc.
补丁方法请求将请求实体中描述的一组更改应用于由请求URI标识的资源。这组更改以一种称为“补丁文档”的格式表示，由媒体类型标识。如果请求URI未指向现有资源，服务器可能会创建新资源，具体取决于修补程序文档类型（是否可以逻辑修改空资源）和权限等。
The difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the resource identified by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version. The PATCH method affects the resource identified by the Request-URI, and it also MAY have side effects on other resources; i.e., new resources may be created, or existing ones modified, by the application of a PATCH.
PUT和PATCH请求之间的差异反映在服务器处理封闭实体以修改请求URI标识的资源的方式上。在PUT请求中，封闭的实体被视为存储在源服务器上的资源的修改版本，客户端请求替换存储的版本。然而，对于补丁，封闭的实体包含一组说明，说明如何修改当前驻留在源服务器上的资源以生成新版本。补丁方法会影响由请求URI标识的资源，并且可能会对其他资源产生副作用；i、 例如，可以通过应用补丁创建新资源，也可以修改现有资源。
PATCH is neither safe nor idempotent as defined by [RFC2616], Section 9.1.
补丁既不安全，也不是[RFC2616]第9.1节定义的幂等元。
A PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes from collisions between two PATCH requests on the same resource in a similar time frame. Collisions from multiple PATCH requests may be more dangerous than PUT collisions because some patch formats need to operate from a known base-point or else they will corrupt the resource. 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.
补丁请求可以以幂等的方式发出，这也有助于防止相同资源上的两个补丁请求在相似的时间范围内发生冲突而产生不良结果。来自多个修补程序请求的冲突可能比PUT冲突更危险，因为某些修补程序格式需要从已知的基点运行，否则会损坏资源。使用此类修补程序应用程序的客户端应使用条件请求，这样，如果自客户端上次访问资源以来资源已更新，则请求将失败。例如，客户端可以在补丁请求的If匹配头中使用强ETag[RFC2616]。
There are also cases where patch formats do not need to operate from a known base-point (e.g., appending text lines to log files, or non-colliding rows to database tables), in which case the same care in client requests is not needed.
还有一些情况下，补丁格式不需要从已知的基点进行操作（例如，将文本行附加到日志文件，或将非冲突行添加到数据库表），在这种情况下，不需要在客户端请求中进行同样的处理。
The server MUST apply the entire set of changes atomically and never provide (e.g., in response to a GET during this operation) a partially modified representation. If the entire patch document cannot be successfully applied, then the server MUST NOT apply any of the changes. The determination of what constitutes a successful PATCH can vary depending on the patch document and the type of resource(s) being modified. For example, the common 'diff' utility can generate a patch document that applies to multiple files in a directory hierarchy. The atomicity requirement holds for all directly affected files. See "Error Handling", Section 2.2, for details on status codes and possible error conditions.
服务器必须以原子方式应用整个更改集，并且从不提供（例如，在此操作期间响应GET）部分修改的表示。如果无法成功应用整个修补程序文档，则服务器不得应用任何更改。根据修补程序文档和所修改的资源类型，确定成功修补程序的内容可能会有所不同。例如，通用的“diff”实用程序可以生成应用于目录层次结构中多个文件的修补程序文档。原子性要求适用于所有直接受影响的文件。有关状态代码和可能的错误条件的详细信息，请参见第2.2节“错误处理”。
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. A response to this method is only cacheable if it
如果请求通过缓存，并且请求URI标识一个或多个当前缓存的实体，则这些条目应视为过时。对此方法的响应只有在
contains explicit freshness information (such as an Expires header or "Cache-Control: max-age" directive) as well as the Content-Location header matching the Request-URI, indicating that the PATCH response body is a resource representation. A cached PATCH response can only be used to respond to subsequent GET and HEAD requests; it MUST NOT be used to respond to other methods (in particular, PATCH).
包含显式新鲜度信息（例如Expires标头或“Cache Control:max age”指令）以及与请求URI匹配的内容位置标头，指示修补程序响应主体是资源表示。缓存的补丁响应只能用于响应后续GET和HEAD请求；它不得用于响应其他方法（尤其是补丁）。
Note that entity-headers contained in the request apply only to the contained patch document and MUST NOT be applied to the resource being modified. Thus, a Content-Language header could be present on the request, but it would only mean (for whatever that's worth) that the patch document had a language. Servers SHOULD NOT store such headers except as trace information, and SHOULD NOT use such header values the same way they might be used on PUT requests. Therefore, this document does not specify a way to modify a document's Content-Type or Content-Language value through headers, though a mechanism could well be designed to achieve this goal through a patch document.
请注意，请求中包含的实体头仅适用于包含的修补程序文档，不得应用于正在修改的资源。因此，请求中可能会出现一个内容语言头，但这只意味着（无论如何）补丁文档有一种语言。服务器不应存储此类头，除非作为跟踪信息，并且不应使用与PUT请求相同的头值。因此，本文档没有指定通过标题修改文档内容类型或内容语言值的方法，尽管可以通过补丁文档设计一种机制来实现这一目标。
There is no guarantee that a resource can be modified with PATCH. Further, it is expected that different patch document formats will be appropriate for different types of resources and that no single format will be appropriate for all types of resources. Therefore, there is no single default patch document format that implementations are required to support. Servers MUST ensure that a received patch document is appropriate for the type of resource identified by the Request-URI.
不能保证可以使用修补程序修改资源。此外，预计不同的补丁文档格式将适用于不同类型的资源，并且没有单一格式适用于所有类型的资源。因此，实现不需要支持单一的默认补丁文档格式。服务器必须确保收到的修补程序文档适合请求URI标识的资源类型。
Clients need to choose when to use PATCH rather than PUT. For example, if the patch document size is larger than the size of the new resource data that would be used in a PUT, then it might make sense to use PUT instead of PATCH. A comparison to POST is even more difficult, because POST is used in widely varying ways and can encompass PUT and PATCH-like operations if the server chooses. 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.
客户端需要选择何时使用补丁而不是放置。例如，如果修补程序文档大小大于将在PUT中使用的新资源数据的大小，则使用PUT而不是修补程序可能是有意义的。与POST进行比较更加困难，因为POST的使用方式千差万别，如果服务器选择，它可以包含PUT和补丁式操作。如果操作没有以可预测的方式修改请求URI标识的资源，那么应该考虑POST而不是PATCH或PUT。
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100
[description of changes]
[更改说明]
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"
HTTP/1.1 204无内容位置：/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.
之所以使用204响应代码，是因为响应不包含消息体（使用200代码的响应将包含该消息体）。请注意，也可以使用其他成功代码。
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.
此外，ETag响应头字段包含通过应用补丁创建的实体的ETag，可在http://www.example.com/file.txt，如内容位置响应标题字段所示。
There are several known conditions under which a PATCH request can fail.
补丁请求可能会在几种已知条件下失败。
Malformed patch document: When the server determines that the patch document provided by the client is not properly formatted, it SHOULD return a 400 (Bad Request) response. The definition of badly formatted depends on the patch document chosen.
格式错误的修补程序文档：当服务器确定客户端提供的修补程序文档格式不正确时，它应该返回400（错误请求）响应。格式错误的定义取决于所选的修补程序文档。
Unsupported patch document: Can be specified using a 415 (Unsupported Media Type) response when the client sends a patch document format that the server does not support for the resource identified by the Request-URI. Such a response SHOULD include an Accept-Patch response header as described in Section 3.1 to notify the client what patch document media types are supported.
不支持的修补程序文档：当客户端发送服务器不支持由请求URI标识的资源的修补程序文档格式时，可以使用415（不支持的媒体类型）响应来指定。此类响应应包括第3.1节所述的接受修补程序响应标头，以通知客户端支持哪些修补程序文档介质类型。
Unprocessable request: Can be specified with a 422 (Unprocessable Entity) response ([RFC4918], Section 11.2) when the server understands the patch document and the syntax of the patch document appears to be valid, but the server is incapable of processing the request. This might include attempts to modify a resource in a way that would cause the resource to become invalid; for instance, a modification to a well-formed XML document that would cause it to no longer be well-formed. There may also be more specific errors like "Conflicting State" that could be signaled with this status code, but the more specific error would generally be more helpful.
不可处理请求：当服务器理解修补程序文档且修补程序文档的语法似乎有效，但服务器无法处理请求时，可以使用422（不可处理实体）响应（[RFC4918]，第11.2节）指定。这可能包括试图以导致资源无效的方式修改资源；例如，对格式良好的XML文档的修改会导致其格式不再正确。也可能有更具体的错误，如“冲突状态”，可以用此状态代码发出信号，但更具体的错误通常会更有帮助。
Resource not found: Can be specified with a 404 (Not Found) status code when the client attempted to apply a patch document to a non-existent resource, but the patch document chosen cannot be applied to a non-existent resource.
未找到资源：当客户端试图将修补程序文档应用于不存在的资源，但所选修补程序文档无法应用于不存在的资源时，可以使用404（未找到）状态代码指定。
Conflicting state: Can be specified with a 409 (Conflict) status code when the request cannot be applied given the state of the resource. For example, if the client attempted to apply a structural modification and the structures assumed to exist did not exist (with XML, a patch might specify changing element 'foo' to element 'bar' but element 'foo' might not exist).
冲突状态：当给定资源的状态无法应用请求时，可以使用409（冲突）状态代码指定。例如，如果客户端试图应用结构修改，而假定存在的结构不存在（对于XML，补丁可能指定将元素“foo”更改为元素“bar”，但元素“foo”可能不存在）。
Conflicting modification: When a client uses either the If-Match or If-Unmodified-Since header to define a precondition, and that precondition failed, then the 412 (Precondition Failed) error is most helpful to the client. However, that response makes no sense if there was no precondition on the request. In cases when the server detects a possible conflicting modification and no precondition was defined in the request, the server can return a 409 (Conflict) response.
冲突修改：当客户端使用If-Match或If-Unmodified-Since头定义前提条件时，该前提条件失败，那么412（前提条件失败）错误对客户端最有帮助。但是，如果请求没有先决条件，那么这种响应就没有意义。如果服务器检测到可能存在冲突的修改，并且请求中未定义任何先决条件，则服务器可以返回409（冲突）响应。
Concurrent modification: Some applications of PATCH might require the server to process requests in the order in which they are received. If a server is operating under those restrictions, and it receives concurrent requests to modify the same resource, but is unable to queue those requests, the server can usefully indicate this error by using a 409 (Conflict) response.
并发修改：修补程序的某些应用程序可能要求服务器按照接收请求的顺序处理请求。如果服务器在这些限制下运行，并且它接收到修改同一资源的并发请求，但无法对这些请求进行排队，则服务器可以使用409（冲突）响应有效地指示此错误。
Note that the 409 Conflict response gives reasonably consistent information to clients. Depending on the application and the nature of the patch format, the client might be able to reissue the request as is (e.g., an instruction to append a line to a log file), have to retrieve the resource content to recalculate a patch, or have to fail the operation.
请注意，409冲突响应为客户提供了合理一致的信息。根据应用程序和修补程序格式的性质，客户端可能能够按原样重新发出请求（例如，向日志文件追加一行的指令），必须检索资源内容以重新计算修补程序，或者必须使操作失败。
Other HTTP status codes can also be used under the appropriate circumstances.
在适当的情况下，也可以使用其他HTTP状态代码。
The entity body of error responses SHOULD contain enough information to communicate the nature of the error to the client. The content-type of the response entity can vary across implementations.
错误响应的实体体应该包含足够的信息，以便将错误的性质传达给客户端。响应实体的内容类型可能因实现而异。
A server can advertise its support for the PATCH method by adding it to the listing of allowed methods in the "Allow" OPTIONS response header defined in HTTP/1.1. The PATCH method MAY appear in the "Allow" header even if the Accept-Patch header is absent, in which case the list of allowed patch documents is not advertised.
服务器可以通过将补丁方法添加到HTTP/1.1中定义的“允许”选项响应头中允许的方法列表中来公布其对补丁方法的支持。即使不存在Accept修补程序标头，修补程序方法也可能出现在“Allow”标头中，在这种情况下，不公布允许的修补程序文档列表。
This specification introduces a new response header Accept-Patch used to specify the patch document formats accepted by the server. Accept-Patch SHOULD appear in the OPTIONS response for any resource that supports the use of the PATCH method. The presence of the Accept-Patch header in response to any method is an implicit indication that PATCH is allowed on the resource identified by the Request-URI. The presence of a specific patch document format in this header indicates that that specific format is allowed on the resource identified by the Request-URI.
本规范引入了一个新的响应头Accept修补程序，用于指定服务器接受的修补程序文档格式。对于支持使用修补程序方法的任何资源，接受修补程序应出现在选项响应中。在响应任何方法时出现Accept Patch标头都是一个隐式指示，表明在请求URI标识的资源上允许使用补丁。此标头中存在特定的修补程序文档格式表示在由请求URI标识的资源上允许该特定格式。
Accept-Patch = "Accept-Patch" ":" 1#media-type
Accept-Patch = "Accept-Patch" ":" 1#media-type
The Accept-Patch header specifies a comma-separated listing of media-types (with optional parameters) as defined by [RFC2616], Section 3.7.
Accept Patch标头指定由[RFC2616]第3.7节定义的以逗号分隔的媒体类型列表（带有可选参数）。
Example:
例子：
Accept-Patch: text/example;charset=utf-8
Accept-Patch: text/example;charset=utf-8
[request]
[请求]
OPTIONS /example/buddies.xml HTTP/1.1
Host: www.example.com
OPTIONS /example/buddies.xml HTTP/1.1
Host: www.example.com
[response]
[答复]
HTTP/1.1 200 OK
Allow: GET, PUT, POST, OPTIONS, HEAD, DELETE, PATCH
Accept-Patch: application/example, text/example
HTTP/1.1 200 OK
Allow: GET, PUT, POST, OPTIONS, HEAD, DELETE, PATCH
Accept-Patch: application/example, text/example
The examples show a server that supports PATCH generally using two hypothetical patch document formats.
示例显示了一个服务器，该服务器通常使用两种假设的修补程序文档格式支持修补程序。
The Accept-Patch response header has been added to the permanent registry (see [RFC3864]).
接受修补程序响应标头已添加到永久注册表（请参阅[RFC3864]）。
Header field name: Accept-Patch
标题字段名称：接受修补程序
Applicable Protocol: HTTP
适用协议：HTTP
Author/Change controller: IETF
作者/变更控制员：IETF
Specification document: this specification
规范文件：本规范
The security considerations for PATCH are nearly identical to the security considerations for PUT ([RFC2616], Section 9.6). These include authorizing requests (possibly through access control and/or authentication) and ensuring that data is not corrupted through transport errors or through accidental overwrites. Whatever mechanisms are used for PUT can be used for PATCH as well. The following considerations apply especially to PATCH.
补丁的安全注意事项与PUT的安全注意事项几乎相同（[RFC2616]，第9.6节）。其中包括授权请求（可能通过访问控制和/或身份验证），并确保数据不会因传输错误或意外覆盖而损坏。用于PUT的任何机制也可以用于PATCH。以下注意事项尤其适用于修补程序。
A document that is patched might be more likely to be corrupted than a document that is overridden in entirety, but that concern can be addressed through the use of mechanisms such as conditional requests using ETags and the If-Match request header as described in Section 2. If a PATCH request fails, the client can issue a GET request to the resource to see what state it is in. In some cases, the client might be able to check the contents of the resource to see if the PATCH request can be resent, but in other cases, the attempt will just fail and/or a user will have to verify intent. In the case of a failure of the underlying transport channel, where a PATCH response is not received before the channel fails or some other timeout happens, the client might have to issue a GET request to see whether the request was applied. The client might want to ensure that the GET request bypasses caches using mechanisms described in HTTP specifications (see, for example, Section 13.1.6 of [RFC2616]).
经过修补的文档可能比被全部重写的文档更容易损坏，但可以通过使用诸如使用ETag的条件请求和If Match请求头等机制来解决该问题，如第2节所述。如果修补程序请求失败，客户端可以向资源发出GET请求，以查看其处于何种状态。在某些情况下，客户端可能能够检查资源的内容，以查看是否可以重新发送修补程序请求，但在其他情况下，尝试将失败，并且/或者用户必须验证其意图。在底层传输通道发生故障的情况下，如果在通道故障或其他超时发生之前未收到修补程序响应，则客户端可能必须发出GET请求以查看是否应用了该请求。客户机可能希望确保GET请求使用HTTP规范中描述的机制绕过缓存（例如，请参见[RFC2616]第13.1.6节）。
Sometimes an HTTP intermediary might try to detect viruses being sent via HTTP by checking the body of the PUT/POST request or GET response. The PATCH method complicates such watch-keeping because neither the source document nor the patch document might be a virus, yet the result could be. This security consideration is not
有时HTTP中介可能会通过检查PUT/POST请求或GET响应的主体来检测通过HTTP发送的病毒。补丁方法使这种监视变得复杂，因为源文档和补丁文档都可能不是病毒，但结果可能是病毒。这一安全考虑并不重要
materially different from those already introduced by byte-range downloads, downloading patch documents, uploading zipped (compressed) files, and so on.
与字节范围下载、下载修补程序文档、上载压缩文件等已经引入的内容有很大不同。
Individual patch documents will have their own specific security considerations that will likely vary depending on the types of resources being patched. The considerations for patched binary resources, for instance, will be different than those for patched XML documents. Servers MUST take adequate precautions to ensure that malicious clients cannot consume excessive server resources (e.g., CPU, disk I/O) through the client's use of PATCH.
单个修补程序文档将有其自己的特定安全注意事项，这些注意事项可能因修补的资源类型而异。例如，修补二进制资源的注意事项将不同于修补XML文档的注意事项。服务器必须采取足够的预防措施，以确保恶意客户端不会通过客户端使用修补程序消耗过多的服务器资源（例如CPU、磁盘I/O）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918]Dusseault，L.，“用于Web分布式创作和版本控制（WebDAV）的HTTP扩展”，RFC4918，2007年6月。
PATCH is not a new concept, it first appeared in HTTP in drafts of version 1.1 written by Roy Fielding and Henrik Frystyk and also appears in Section 19.6.1.1 of RFC 2068.
补丁并不是一个新概念，它首先出现在由Roy Fielding和Henrik Frystyk编写的1.1版草稿中的HTTP中，也出现在RFC 2068的第19.6.1.1节中。
Thanks to Adam Roach, Chris Sharp, Julian Reschke, Geoff Clemm, Scott Lawrence, Jeffrey Mogul, Roy Fielding, Greg Stein, Jim Luther, Alex Rousskov, Jamie Lokier, Joe Hildebrand, Mark Nottingham, Michael Balloni, Cyrus Daboo, Brian Carpenter, John Klensin, Eliot Lear, SM, and Bernie Hoeneisen for review and advice on this document. In particular, Julian Reschke did repeated reviews, made many useful suggestions, and was critical to the publication of this document.
感谢亚当·罗奇、克里斯·夏普、朱利安·雷什克、杰夫·克莱姆、斯科特·劳伦斯、杰弗里·莫格尔、罗伊·菲尔丁、格雷格·斯坦、吉姆·路德、亚历克斯·罗斯科夫、杰米·洛基、乔·希尔德布兰德、马克·诺丁汉、迈克尔·巴罗尼、塞勒斯·达布、布赖恩·卡彭特、约翰·克莱辛、艾略特·李尔、SM和伯尼·霍内森对本文件的审查和建议。特别是，朱利安·雷什克（Julian Reschke）进行了反复审查，提出了许多有用的建议，对本文件的出版至关重要。
Authors' Addresses
作者地址
Lisa Dusseault Linden Lab 945 Battery Street San Francisco, CA 94111 USA
Lisa Dusseault Linden实验室945电池街旧金山，CA 94111美国
EMail: lisa.dusseault@gmail.com
EMail: lisa.dusseault@gmail.com
James M. Snell
詹姆斯·M·斯内尔
EMail: jasnell@gmail.com
URI: http://www.snellspace.com
EMail: jasnell@gmail.com
URI: http://www.snellspace.com