HTTP 用の PATCH メソッド

1. 序論

この仕様は、 新たな~HTTP11 `RFC2616$r ~methodとして `PATCH$m を定義する。 それは、 `資源$に部分的な改変を適用するために利用される。 ◎ This specification defines the new HTTP/1.1 [RFC2616] method, PATCH, which is used to apply partial modifications to a resource.

新たな~methodは、［ 相互運用能を改善する／~errorを防止する ］ことが必要yである。 `PUT$m ~methodは、 すでに，`資源$を新たな`内容$で完全に上書するものと定義されているので、 部分的な変更を行うものとして再利用することはできない。 さもなければ、 `~proxy$や`~cache$, あるいは`~client$や`~server$までも，演算の結果を【再利用しなかったときと】混同し得る。 `POST$m は、 すでに利用されているが，相互運用能は広くない （一例として，~patch形式の~supportを発見するための標準な仕方は無い）。 `PATCH$m は、 以前の~HTTP仕様にも言及されていたが， 完全には定義されていなかった。 ◎ 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.

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

加えて，この文書は… 【以下、この段落の内容（~ABNF構文）は`~HTTP日本語訳 共通~page＠~HTTPcommon#syntax-notation$に移譲。】 【！`2616/2.1$rfc にて定義される~ABNF構文を利用する。】 ◎ Furthermore, this document uses the ABNF syntax defined in Section 2.1 of [RFC2616].

【この訳に特有な表記規約】

この訳では、 この仕様が公表された当時の~HTTP仕様（ `RFC2616$r ）を参照している箇所を， 現在の中核~HTTP仕様~内の`等価な記述を指すよう改めている＠~HTTPcommon#_terms-convention$。 主なものとして：

• `entitiy^en（`2616/7$rfc）／ `entitiy body^en（`2616/7.2$rfc） → `内容$
• `message body^en ／ `body^en → `内容$ （この仕様においては、 `entitiy body^en と同義に解釈して差し支えない。）
• “`Request-URI$p により識別される資源” → `~target資源$
• `Request-URI$p → `~target~URI$
• その他の各種［ `~header$, `要請~method$, `状態s~code$ ］など

2. `PATCH^m ~method

`PATCH^m ~methodは、 `~target資源$に対し，要請の`内容$内に記述される一連の変更を適用するよう要請する。 この一連の変更は、 `~patch文書@ と呼ばれる，ある`~MIME型$により識別される形式で表現される。 `~target~URI$が既存の`資源$を~~指していない場合、 `~server$は［ ~patch文書の型（~~存在しない資源を論理的に改変できるかどうか）, 【資源に対する改変の】許可, 等々 ］に依存して，新たな`資源$を作成してもヨイ。 ◎ 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.

`PUT$m 要請と `PATCH^m 要請の相違は、［ `~server$が`~target資源$を改変するために，同封された`内容$を処理する仕方 ］に反映される。 `PUT$m 要請においては、 同封された`内容$は［ `生成元~server$上に格納されている`資源$を改変した~version ］であり，［ `~client$は，格納-済み~versionを置換するよう要請している ］と見なされる。 一方で， `PATCH^m 要請においては、 同封された`内容$は［ `生成元~server$上に現在~滞在している資源を，新たな~versionを生産するためにどう改変するべきか ］を述べる，一連の指示書きを包含する。 `PATCH^m ~methodは、 `~target資源$に影響することに加え，他の資源に副作用があってもヨイ — すなわち， `PATCH^m の適用により、 新たな資源が作成されたり，既存のものが改変され得る。 ◎ 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.

`PATCH^m は、 `安全$でも`冪等$でもない。 【！`2616-9.1$rfc に定義されるように】 ◎ PATCH is neither safe nor idempotent as defined by [RFC2616], Section 9.1.

`PATCH^m 要請は、 冪等になるような仕方で発行でき， ある時間枠~内で同じ`資源$に対し複数の `PATCH^m 要請が衝突して不良な結果になるのを防止する助けになる。 複数の `PATCH^m 要請による衝突は `PUT$m の衝突より危険になり得る — ~patch形式には，既知な基点から演算する必要があるものもあり、 そうしないと資源を破損することになるので。 この種類の~patch応用を利用している`~client$は、［ ~clientが最後に資源に~accessしてから，資源が更新された場合には、 要請は失敗することになる ］よう，条件付き要請を利用するベキである — 例えば~clientは、 `PATCH^m 要請の `If-Match$h ~header内に強い `ETag$h 【以前の要請に対する応答の `ETag$h ~headerから得られた`強い検証子$】 を利用できる。 【！[RFC2616]】 ◎ 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.

~patch形式が既知な基点から演算する必要がない事例もある （例：~log~fileに~text行lを付加する／~database~tableに他と衝突しない~rowを付加する） — その事例では、 ~client要請において同じ~careは必要ない。 ◎ 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.

`~server$は、 一連の変更~すべてを不可分に適用しなければナラナイ — 部分的に改変された表現は決して供することのないよう （例：この演算の間の `GET$m に対する応答）。 `~patch文書$全体が成功裡に適用できなかった場合、 `~server$は，いかなる変更も適用してはナラナイ。 何をもって成功裡な `PATCH^m とされるかの決定は、 ~patch文書と改変されている`資源$（たち）の型に依存して，変わり得る。 例えば，共通的な “diff” ~utilityは、 ある~directory階層~内の複数の~fileに適用するような~patch文書を生成し得る。 不可分性の要件は、 直に影響されるすべての~fileに課される。 `状態s~code$とアリな~error条件についての詳細は、 `~errorの取扱い＠#error.handling§を見よ。 ◎ 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.

【 `正誤表 #3169＠~ERRATA/eid3169$（ `Verified^en ）により、 次の 2 つの段落を追加するよう示唆されている： 】

• `PATCH^m 要請を`資源$【`~target資源$】の状態に適用する手段は、 要請【の`内容$を成す`~patch文書$】の~MIME型により決定される。 `PATCH^m 要請を受信した`~server$は、［ その要請に伴われる~MIME型の仕様が， `PATCH^m に特有な意味論を定義しない場合 ］には、 状態s~code `415$st を返すことにより，要請を却下するベキである — もっと特有な~error`状態s~code$が優先されない限り。 ◎ 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.
• 特に，`~server$は、 `PATCH^m 意味論を定義しない汎用な~MIME型 — "`application/xml^c" や "`application/json^c" など — に対し，そのような意味論があると見做すベキでない。 そうすると，`PATCH^m の意味論が［ 一般ではなく，`資源$ごとに特有になる ］ので、 相互運用能に課題をもたらすことになる。 ◎ 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.

要請が~cacheを通過する, かつ その`~target~URI$は現在~cacheされている 1 個~以上の`内容$を識別する場合、 それらの~entryは`非新鮮$として扱うベキである。 この~methodに対する応答が`~cache可能$になるのは、 それが，［ `PATCH^m 応答の`内容$は，ある`資源$の表現であることを指示する ］ような［ 明示的な鮮度~情報（ `Expires$h ~headerや `max-age$sdir `~cache指令$など）や `~target~URI$に合致している `Content-Location$h ~header ］を包含する場合に限られる。 ~cache済み `PATCH^m 応答を利用できるのは、 後続な［ `GET$m ／ `HEAD$m ］要請に応答するために限られる — 他の~method（特に， `PATCH^m ）に対する応答に利用してはナラナイ。 ◎ 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).

要請~内に包含される `entity-header^p 【 `2616/7.1$rfc （概ね，`表現~header$が該当する）】 は、 同じ要請が包含する`~patch文書$のみに適用され，改変される`資源$に適用してはナラナイことに注意。 したがって、 要請に `Content-Language$h ~headerが在ったとしても， それは当の~patch文書に何らかの言語があることしか意味しない （それが何のためにあるかを問わず）。 `~server$は、 そのような~headerを — ~trace情報としてを除いて — 格納したり，その~header値を `PUT$m 要請に利用され得るときと同じ仕方で利用するベキでない。 したがって，この文書は、 そのような~headerを通して文書の `Content-Type$h や `Content-Language$h 値を改変する仕方は指定しない — ~patch文書を通して この目標を達成するような仕組みを，上手く設計することもできるが。 ◎ 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.

`PATCH^m で`資源$が改変できる保証は無い。 更に，適切になる~patch文書~形式は、 資源の型ごとに異なるものと予期され，どの型の資源にも適切になるような単独の形式は無い。 したがって、 実装が~supportするよう要求される，既定の~patch文書~形式も無い。 `~server$は、 受信した`~patch文書$が`~target資源$の型に適切になることを確保しなければナラナイ。 ◎ 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.

`~client$は、 いつ `PUT$m ではなく `PATCH^m を利用するか選ぶ必要がある。 例えば，`~patch文書$の~sizeが `PUT$m 内で利用される新たな資源~dataの~sizeより大きい場合、 `PATCH^m に代えて `PUT^m を利用する方がイミを成すかもしれない。 `POST$m との比較は、 もっと困難である — `POST^m が利用される仕方は多様であり、 `PUT^m 演算が `PATCH^m の様な演算も包摂し得るよう，`~server$が選ぶ場合もあるので。 当の演算が`~target資源$を［ `PATCH^m ~MIME型の意味論に定義される†，予測-可能な仕方 ］で改変しない場合、 `PATCH^m や `PUT$m に代えて `POST$m を考慮するべきである。 【† `正誤表 #3169＠~ERRATA/eid3169$（ `Verified^en ）による挿入】 ◎ 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.

2.1. 単純な `PATCH^m の例

PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100


（…変更の記述）
◎
[description of changes]

HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"

2.2. ~errorの取扱い

`PATCH$m 要請が失敗し得る条件として、 以下に挙げるものが既知である： ◎ There are several known conditions under which a PATCH request can fail.

`~patch文書$は不正形である： ◎ Malformed patch document:

`~server$は、 `~client$から供された~patch文書は適正な形式でないものと決定したときは， `400$st 応答を返すベキである。 何をもって形式は不良と定義されるかは、 選ばれた~patch文書に依存する。 ◎ 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.

~supportされない`~patch文書$： ◎ Unsupported patch document:

`~server$は，［ `~client$が送信してきた~patch文書の形式を`~target資源$用には~supportしない ］ときは、 `415$st 応答を利用して，そのことを指定できる。 `3.1§ に述べるように，そのような応答は、 `Accept-Patch$h 応答~headerを内包して，どの~patch文書~MIME型なら~supportするかを`~client$に通知するベキである。 ◎ 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.

処理-不能な要請： ◎ Unprocessable request:

［ `~server$は`~patch文書$を解する ］かつ［ ~patch文書の構文は妥当に出現している ］が，当の要請を処理する能力がない場合、 `~server$は， `422$st 応答【！ `4918/11.2$rfc 】で，そのことを指定できる。 これには、 `資源$を妥当でなくする仕方で資源を改変しようとする試みも含まれ得る — 一例として、 整形式であった~XML文書を そうでなくするような改変など。 この`状態s~code$には， “`Conflicting State^en（状態が競合している）” の様な より特定な~errorも【`表現$として？】伴わせて通達でき、 一般に，より助けになろう。 【！but？】 ◎ 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.

資源が見出されなかった： ◎ Resource not found:

`~client$が`~patch文書$を適用しようと試みた`資源$は，存在しないので適用できなかったときは、 状態s~code `404$st で，そのことを指定できる。 ◎ 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.

状態が競合している： ◎ Conflicting state:

当の`資源$の所与の状態の下では，要請を適用できなかったときは、 状態s~code `409$st で，そのことを指定できる。 例えば，`~client$が構造上の改変を適用しようと試みたが、 存在するものと見做された構造は存在しない場合 （例：~patchは，~XML資源の要素 'foo' を要素 'bar' に変更しようと指定したが、 要素 'foo' は存在しないかもしれない）。 ◎ 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).

改変が競合している： ◎ Conflicting modification:

`~client$が ある事前条件を定義する［ `If-Match$h ／ `If-Unmodified-Since$h ］~headerを利用していて，その事前条件が失敗した場合、 ~clientにとっては `412$st ~errorが最も助けになる。 しかしながら，要請に事前条件が無かった場合、 そのような応答はイミを成さない。 `~server$は、［ 改変が競合している可能性があり，要請~内に定義される事前条件は無い ］ことを検出したときは， `409$st 応答を返せる。 ◎ 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.

同時並行な改変： ◎ Concurrent modification:

`PATCH$m の一部の応用は、［ `~server$が，各~要請を受信した順序で処理すること ］を要求するかもしれない。 `~server$は，［ そのような制約の下で演算していて，同じ`資源$を改変する複数の要請を同時並行に受信したが、 それらの要請を~queue不能な場合 ］、 `409$st 応答を利用して，この~errorを有用に指示できる。 ◎ 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$st 応答は、 適度に一貫した情報を~clientに与えることに注意。 応用, および~patch形式の資質に依存して、 `~client$は ⇒＃ 要請をそのまま発行し直せることも（例：ある~log~fileに行lを付加するような指示書き）, 当の資源~内容を検索取得して~patchを計算し直す必要があることも, 当の演算を失敗させるしかないこともある。 ◎ 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.

他の`状態s~code$も，適切な状況下で利用できる。 ◎ Other HTTP status codes can also be used under the appropriate circumstances.

~error応答の`内容$は、 `~client$に向けて~errorの資質を通信する十分な情報を包含するベキである。 応答の`内容$の内容~型は、 各~実装~間で変わり得る。 ◎ 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.

3. `OPTIONS^m ~methodにおける広告-法の~support

`~server$は、 自身による `PATCH$m ~methodの~supportを広告できる — その~header名を［ `OPTIONS$m 要請に対し、 ~HTTP11にて定義される `Allow$h 応答~header内に，許容される~methodの一つとして追加する ］ことにより。 `PATCH^m ~methodは、 `Accept-Patch$h ~headerが無いときでも， `Allow$h ~header内に出現してヨイ — その事例では、 許容される~patch文書【形式】の~listは広告されない。 ◎ 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.

3.1. `Accept-Patch^h ~header

この仕様は、 新たな応答~header `Accept-Patch^h を導入する。 それは、 `~server$が受容する~patch文書~形式を指定するために利用される。 `Accept-Patch^h は、 `資源$が `PATCH$m ~methodの利用を~supportするならば， 資源~向けの `OPTIONS$m 要請に対する応答~内に出現するベキである。 ~methodを問わず，応答に `Accept-Patch^h ~headerが在ることは、［ `PATCH$m は，`~target資源$に対し許容される ］ことを暗黙的に指示する。 この~headerに特定の~patch文書~形式が在ることは、 その形式は`~target資源$に対し許容されることを指示する。 ◎ 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-Patch
	= 1#`media-type$p

`Accept-Patch^h ~headerは、 ~commaで分離された `media-type$p 【！`2616/3.7$rfc 省略可能な~parameterも伴う】 の~listを指定する。 ◎ The Accept-Patch header specifies a comma-separated listing of media-types (with optional parameters) as defined by [RFC2616], Section 3.7.

Accept-Patch: text/example;charset=utf-8

3.2. `OPTIONS$m 要請と応答の例

OPTIONS /example/buddies.xml HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Allow: GET, PUT, POST, OPTIONS, HEAD, DELETE, PATCH
Accept-Patch: application/example, text/example

4. ~IANA考慮点

5. ~securityの考慮点

`PATCH$m に対する~securityの考慮点は、 `PUT$m 【！ `2616/9.6$rfc 】に対するそれに近い。 これらには、［ （場合によっては、~access制御や認証を通して）権限付与している要請 ］, および［ ~transport~errorや偶発的な上書-を通して，~dataが破損することはないことを確保すること ］も含まれる。 `PUT$m 用に利用される仕組みは、 何であれ `PATCH$m にも利用できる。 とりわけ， `PATCH$m には、 以下の考慮点が適用される： ◎ 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.

~patchされた文書は， まるごと上書きされた文書より破損する見込みは高いかもしれないが、 その懸念には，［ `ETag$h を利用する`条件付き要請$や, `2§ に述べたような `If-Match$h 要請~header ］などの仕組みの利用を通して取組める。 `PATCH$m 要請が失敗した場合、 `~client$は，当の`資源$に対し `GET$m 要請を発行して資源の状態がどうなっているかを見れる。 一部の事例では，~clientは、 `PATCH$m 要請を送信し直せるかどうか見るため，資源の内容を検査-可能かもしれないが、 その試みが単に失敗したり，その意図を利用者が検証yする必要まである事例もある。 下層~transport~channelにおける失敗の事例 — ~channelが失敗する前までに `PATCH$m 応答は受信されなかったか，他の何らかの時間切れが起きたときなど — においては、 ~clientは `GET$m 要請を発行して，要請が適用されたかどうか見る必要があるかもしれない。 ~clientは、~HTTP仕様に述べられる仕組みを利用して （例えば `2616/13.1.6$rfc 【`~cache指令$】を見よ）， `GET$m 要請が~cacheを迂回することを確保したいと求めるかもしれない ◎ 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]).

`媒介者$は、 ときには，［ `PUT$m 要請 ／ `POST$m 要請 ／［ `GET$m 要請に対する応答 ］］の`内容$を検査することにより，~HTTPを介して送信されている~virusを検出しようと試行するかもしれない。 `PATCH$m ~methodは、 そのような~~監視法を複雑化する — ~source文書, `~patch文書$のどちらにも~virusが無くとも、 結果は~virusになり得るので。 この~securityの考慮点は、 すでに［ 【`範囲~要請$による】`~byte範囲$の~download ／ ~patch文書の~download法 ／ ~zipされた（圧縮-済み）~fileの~upload法 ］等々により導入されたものと，さほど異なるものではない。 ◎ 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.

個々の`~patch文書$には、 自前の特有な~securityの考慮点があり， ~patchされている`資源$の型に依存して変わる見込みが高い。 一例として、 ~patchされる資源が~binaryであるときの考慮点は，~XML文書のときと異なるであろう。 `~server$は、［ 悪意的な~clientが `PATCH$m の利用を通して，~server資源（例： ~CPU, ~disk I/O ）を過度に消費する ］のを~~防ぐために必要十分な予防策を講じなければナラナイ。 ◎ 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.

A. 謝辞

`PATCH$m は新たな概念ではなく、 `Roy Fielding^en, `Henrik Frystyk^en 各氏により書かれた~HTTP11の草案にて最初に出現し、 `2068/19.6.1.1$rfc にも出現した。 ◎ 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.

この文書を考査して，助言を寄せられた次の方々に感謝する：

特に， `Julian Reschke^en 氏は、 何度も考査され, 有用な示唆を寄せられ，この文書の公表に欠かせなかった。 ◎ In particular, Julian Reschke did repeated reviews, made many useful suggestions, and was critical to the publication of this document.