[要約] RFC 5789は、HTTPのPATCHメソッドに関する仕様を定めたものであり、既存のリソースの一部を更新するためのメソッドです。このRFCの目的は、PUTメソッドでは不適切な場合に、リソースの部分的な更新を可能にすることです。
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.
HyperText Transfer Protocol（HTTP）を拡張するいくつかのアプリケーションでは、部分的なリソース変更を行う機能が必要です。既存のHTTP PUTメソッドは、ドキュメントの完全な交換のみを可能にします。この提案は、既存のHTTPリソースを変更するために、新しい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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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]メソッドであるパッチを定義します。
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メソッドは、完全な新しいボディでリソースを上書きするために既に定義されており、部分的な変更を行うために再利用することはできません。それ以外の場合、プロキシやキャッシュ、さらにはクライアントやサーバーでさえ、操作の結果に関して混乱する可能性があります。投稿はすでに使用されていますが、幅広い相互運用性がありません（1つは、パッチ形式のサポートを発見する標準的な方法はありません）。パッチは以前の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].
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうすべき」、「そうでない」、「推奨」、「5月」、および「オプション」[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が既存のリソースを指していない場合、サーバーは、パッチドキュメントの種類（nullリソースを論理的に変更できるかどうか）に応じて、新しいリソースを作成する場合があります。
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.
プット要求とパッチ要求の違いは、サーバーが囲まれたエンティティを処理してリクエスト-RIによって識別されるリソースを変更する方法に反映されています。PUTリクエストでは、囲まれたエンティティはOrigin Serverに保存されているリソースの変更されたバージョンと見なされ、クライアントは保存バージョンを交換することを要求しています。ただし、パッチを使用すると、囲まれたエンティティには、Origin Serverに現在居住しているリソースを変更して新しいバージョンを作成する方法を説明する一連の命令が含まれています。パッチ方法は、リクエスト-URIによって識別されるリソースに影響を与え、他のリソースに副作用がある場合もあります。つまり、パッチの適用により、新しいリソースが作成されるか、既存のリソースが変更される場合があります。
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.
パッチリクエストは、同様のリソース上の2つのパッチ要求間の衝突による悪い結果を防ぐのにも役立つように、同様のリソースでの2つのパッチ要求の間の衝突を防ぐのに役立ちます。一部のパッチ形式が既知のベースポイントから動作する必要があるか、リソースが破損するため、複数のパッチリクエストからの衝突は衝突するよりも危険な場合があります。この種のパッチアプリケーションを使用するクライアントは、クライアントが最後にリソースにアクセスしてからリソースが更新された場合にリクエストが失敗するように条件付き要求を使用する必要があります。たとえば、クライアントは、パッチリクエストの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.
サーバーは、変更のセット全体を原子的に適用する必要があり、部分的に修正された表現を提供することはありません（たとえば、この操作中の取得に応じて）提供しません。パッチドキュメント全体を正常に適用できない場合、サーバーは変更を適用してはなりません。パッチの成功を構成するものの決定は、パッチドキュメントと変更されるリソースのタイプによって異なる場合があります。たとえば、一般的な「diff」ユーティリティは、ディレクトリ階層内の複数のファイルに適用されるパッチドキュメントを生成できます。Atomicity要件は、直接影響を受けるすべてのファイルに保持されます。ステータスコードと可能なエラー条件の詳細については、「エラー処理」、セクション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 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).
リクエストがキャッシュを通過し、リクエスト-URIが現在キャッシュされたエンティティを1つ以上識別した場合、それらのエントリは古いものとして扱う必要があります。この方法への応答は、明示的な新鮮さ情報（有効期限がヘッダーまたは「キャッシュコントロール：最大時代」指令など）とリクエスト-URIに一致するコンテンツロケーションヘッダーが含まれている場合にのみキャッシュ可能です。応答本体はリソース表現です。キャッシュされたパッチ応答は、後続のGETおよびヘッドリクエストに応答するためにのみ使用できます。他の方法（特にパッチ）に応答するために使用してはなりません。
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.
リソースをパッチで変更できるという保証はありません。さらに、さまざまなパッチドキュメント形式がさまざまな種類のリソースに適しており、あらゆる種類のリソースに適切な形式が適切ではないことが予想されます。したがって、実装がサポートする必要がある単一のデフォルトパッチドキュメント形式はありません。サーバーは、受信したパッチドキュメントが、Request-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およびPatchのような操作を含めることができるからです。操作がリクエスト-URIによって識別されたリソースを予測可能な方法で変更しない場合、パッチまたはプットの代わりに投稿を考慮する必要があります。
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応答ヘッダーフィールドには、コンテンツロケーション応答ヘッダーフィールドで示されるように、http：//www.example.com/file.txtで入手可能なパッチを適用することで作成されたエンティティのETAGが含まれています。
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.
サポートされていないパッチドキュメント：415（サポートされていないメディアタイプ）応答を使用して指定できます。クライアントが、リクエスト-URIによって識別されたリソースをサーバーがサポートしていないパッチドキュメント形式を送信する場合。このような応答には、セクション3.1で説明されているAccect-Patch応答ヘッダーを含める必要があります。
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」を要素「バー」に変更するかもしれませんが、要素「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マッチまたは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で定義された「許可」オプション応答ヘッダーの許可メソッドのリストに追加することにより、パッチメソッドのサポートを宣伝できます。パッチメソッドは、受け入れパッチヘッダーが存在しない場合でも「許容」ヘッダーに表示される場合があります。その場合、許可されたパッチドキュメントのリストは宣伝されていません。
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.
この仕様では、サーバーが受け入れたパッチドキュメント形式を指定するために使用される新しいResponse Header Accept-Patchを導入します。Accept-Patchは、パッチメソッドの使用をサポートするリソースのオプション応答に表示される必要があります。任意のメソッドに応答した受け入れパッチヘッダーの存在は、リクエスト-URIによって識別されたリソースでパッチが許可されていることを暗黙的に示しています。このヘッダーに特定のパッチドキュメント形式の存在は、リクエスト-URIによって識別されたリソースで特定の形式が許可されていることを示しています。
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
[request]
[リクエスト]
OPTIONS /example/buddies.xml HTTP/1.1 Host: www.example.com
options/example/buddies.xml http/1.1ホスト：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許可：取得、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.
例は、一般に2つの仮想パッチドキュメント形式を使用してパッチをサポートするサーバーを示しています。
The Accept-Patch response header has been added to the permanent registry (see [RFC3864]).
Accept-Patch応答ヘッダーは永続的なレジストリに追加されました（[RFC3864]を参照）。
Header field name: Accept-Patch
ヘッダーフィールド名：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に使用されるメカニズムは、パッチにも使用できます。以下の考慮事項は、特にパッチにも当てはまります。
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]).
パッチされたドキュメントは、完全にオーバーライドされたドキュメントよりも破損する可能性が高いかもしれませんが、その懸念は、ETAGSを使用した条件付き要求やセクション2で説明されているIFマッチ要求ヘッダーなどのメカニズムを使用することで対処できます。。パッチ要求が失敗した場合、クライアントはリソースにGETリクエストを発行して状態を確認できます。場合によっては、クライアントはリソースのコンテンツを確認して、パッチ要求がresすることができるかどうかを確認できる場合があります。、しかし、他の場合には、試みが失敗するだけでなく、ユーザーは意図を検証する必要があります。チャンネルが失敗する前にパッチ応答が受信されない、または他のタイムアウトが発生する前にパッチ応答が受信されない、基礎となる輸送チャネルの障害が発生した場合、クライアントはリクエストが適用されたかどうかを確認するためにGETリクエストを発行する必要がある場合があります。クライアントは、HTTP仕様に記載されているメカニズムを使用して、GETリクエストがキャッシュをバイパスすることを保証する場合があります（たとえば、[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 materially different from those already introduced by byte-range downloads, downloading patch documents, uploading zipped (compressed) files, and so on.
HTTP仲介者が、Put/Postリクエストの本文をチェックするか、応答を取得することにより、HTTPを介して送信されるウイルスを検出しようとする場合があります。パッチメソッドは、ソースドキュメントもパッチドキュメントもウイルスではない可能性があるため、そのような時計維持を複雑にしますが、結果はそうである可能性があります。このセキュリティの考慮事項は、バイトレンジのダウンロード、パッチドキュメントのダウンロード、ziptip（圧縮）ファイルのアップロードなどによって既に導入されたものと実質的に違いはありません。
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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-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拡張機能」、RFC 4918、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.
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 Carterter、この文書に関するレビューとアドバイスについて、ジョン・クレンシン、エリオット・リア、SM、バーニー・ホネイゼン。特に、Julian Reschkeは繰り返しレビューを行い、多くの有用な提案を行い、この文書の出版に不可欠でした。
Authors' Addresses
著者のアドレス
Lisa Dusseault Linden Lab 945 Battery Street San Francisco, CA 94111 USA
Lisa Dusseault Linden Lab 945 Battery Street San Francisco、CA 94111 USA
EMail: lisa.dusseault@gmail.com
James M. Snell
ジェームズ・M・スネル
EMail: jasnell@gmail.com
URI: http://www.snellspace.com