[14] If-Match: ヘッダーと If-None-Match: ヘッダーは、 起源鯖の資源が指定した条件に一致する、またはしない場合のみ処理を実行するべきという条件付き要求であることとその条件を表します。
If-Match:
If-None-Match:
[6] If-Match: ヘッダーや If-None-Match: ヘッダーは、 要求メソッドを条件付きとするものです >>3, >>21。 対象資源が指定された条件に一致する、またはしない時に要求で指定された処理を実行するべきことを表します。
[9] If-Match: や If-None-Match: の値は、 * か、 または1つ以上の実体タグのリスト (#) です >>3, >>21。
*
#
,
[15] If-Match: は、 複数の利用者エージェントが同じ資源を並列に操作するかもしれない場合の上書き事故 (「lost update」問題) を防ぐために状態を変更する POST、 PUT、DELETE のようなメソッドと併用されることが多いです。 >>3
POST
PUT
DELETE
[33] If-None-Match: * は安全でない PUT のような要求メソッドを使ってクライアントが現在の表現を持たないを操作しようとする時に、 意図せず既存の表現を編集してしまう一種の「lost update」問題 を避けるために使うことができます。 >>21
If-None-Match: *
[16] If-Match: は安全メソッドで、 選択された表現の一部または全部が既に蓄積されている時に要求を中断するために使うこともできます >>3。
[32] If-None-Match: は条件付きGET要求で、 最小のオーバーヘッドでキャッシュ情報を効率的に更新するために使います。 クライアントは、実体タグつきで蓄積されている応答をいくつか更新したい時は、 GET 要求時にそれらの実体タグを含む If-None-Match: を生成するべきです。 >>21
GET
[20] 内容折衝などの理由で同じ URL に複数の表現が存在することもあり、 クライアントが複数のキャッシュ項目を保持していることがあるので、 実体タグを複数指定することもできます。
[37] A-IM: ヘッダーに差分符号化が含まれる場合は、 If-None-Match: ヘッダーに当該要求URL に対する以前の応答から得た1つ以上の実体タグを含めなければなりません >>36。
A-IM:
[34] 差分符号化を使う場合には、クライアントが (そのものまたは復元するのに十分な差分を) 保持している実現値を明示し、 基準となる実現値を鯖に選ばせるために If-None-Match: ヘッダーに複数の実体タグを指定することができます >>19。
[40] HTTP認証の challenge を取得するために、 ダミーの実体タグを If-Match: ヘッダーに指定する技法があります。
[42] PATCH 要求を使って基準となる表現に対する差分を送信する場合は、 If-Match: ヘッダーに実体タグを指定するべきです >>41。
PATCH
[7] If-Match: * が指定された時は、 対象資源が最低1つ現在の表現を有していれば、 条件を満たします >>3。
If-Match: *
[24] If-None-Match: * が指定された時は、 対象資源が1つも現在の表現を有していないなら、 条件を満たします >>21。
[8] If-Match: に実体タグが指定された時は、 そのいずれかが対象資源の現在の表現に一致すれば、 条件を満たします。ただし起源鯖は強い比較を使わなければなりません。 >>3
[25] If-None-Match: に実体タグが指定された時は、 そのいずれも選択された表現の実体タグに一致しなければ、 条件を満たします。ただし受信者は弱い比較を使わなければなりません。 >>21
[18] Meter の利用回数報告のために使う条件付き要求の場合、 実体タグを複数指定することはできません。
Meter
[17] If-Match: や If-None-Match: の処理については、条件付き要求の項をご覧ください。
[35] 差分符号化に関しては、差分符号化の項を参照してください。
[38] キャッシュにおける差分符号化の処理については、226 を参照。
226
The If-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field. Entity tags are defined in section 3.11. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used, on updating requests, to prevent inadvertent modification of the wrong version of a resource. As a special case, the value "*" matches any current entity of the resource.
If-Match 要求頭欄は、それを条件付とする方式と共に使います。 以前に資源から得た1個か複数個の実体を持っているクライアントは、 その実体群の1つが現行のものであることを、 If-Match 頭欄にそれらの実体と関連付けられた実体札の並びを含めることで検証できます。実体札は3.11節で定義しています。 この機能の目的は、キャッシュした情報の効果的な更新最小限のやり取り overhead で実現することです。この機能は、資源の誤った版を不注意に修正してしまうことを防ぐためにも使えます。 特別な場合として、値 * は資源の現在の実体に一致します。
If-Match
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource, then the server MAY perform the requested method as if the If-Match header field did not exist.
実体札のいずれかが同様の (If-Match 頭なしの) GET 要求への応答で返されるであろう実体の実体札と一致するか、 または * が与えられ、その資源に現在の実体が存在するなら、 サーバーは If-Match 頭欄が存在しないかのように要求された方式を処理して構いません。
A server MUST use the strong comparison function (see section 3.11 13.3.3) to compare the entity tags in If-Match.
サーバーは、 If-Match 中の実体札を比較するのに強い比較関数を使わなければなりません。
If none of the entity tags match, or if "*" is given and no current entity exists, the server MUST NOT perform the requested method, and MUST return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method, such as PUT, from modifying a resource that has changed since the client last retrieved it.
実体札のどれもが一致しなかったか、または * が与えられたものの現在実体が存在しない場合は、サーバーは要求された方式を実行してはならず、 412 (前条件失敗) 応答を返さなければなりません。 この振る舞いは、 PUT のような更新する方式で、 クライアントが最後にそれを取り出してから変更されている資源を修正してしまうことを防ぎたい時に有用です。
412
If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status, then the If-Match header MUST be ignored.
If-Match 頭欄がなければ要求の結果が 2xx 状態または 412 状態以外のものになるとしたら、 If-Match 頭は無視しなければなりません。
2xx
The meaning of "If-Match: *" is that the method SHOULD be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see section 14.43 14.44) exists, and MUST NOT be performed if the representation does not exist.
If-Match: * の意味は、その方式は起源サーバーによって (またはキャッシュによって、もしかすると Vary 機構を使って) 選択された表現が存在するときに実行されるべきであり、 表現が存在しないときには実行してはならないということです。
Vary
A request intended to update a resource (e.g., a PUT) MAY include an If-Match header field to signal that the request method MUST NOT be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without their knowledge.
資源を更新する意図の要求 (例えば PUT) は、 If-Match 値 (1つの実体札) の対応する実体がもはやその資源の表現ではないときにその要求方式を適用してはならないことを通知するために If-Match 頭欄を含めても構いません。 これにより、利用者が、彼らの知識なしに資源が変更されているとしたら要求が成功することを望まないことを示すことができます。
Examples:If-Match: "xyzzy"If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"If-Match: *
Examples:
The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields is undefined by this specification.
If-Match 頭欄と If-None-Match 頭欄または If-Modified-Since 頭欄のいずれかを持っている要求の結果は子の仕様書では未定義とします。
If-None-Match
If-Modified-Since
The If-None-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used, on updating requests, to prevent a method (e.g. PUT) inadvertent modification of a resource which was not known to from inadvertently modifying an existing resource when the client believes that the resource does not exist.
If-None-Match 要求頭欄は、それを条件付とする方式とともに使います。 以前に資源から得た1個か複数個の実体を持っているクライアントは、その実体群のどれもが現行のものではないことを、 If-None-Match 頭欄にそれらの実体と関連付けられた実体札の並びを含めることで検証できます。 この機能の目的は、キャッシュした情報の効果的な更新を最小限のやり取り overhead で実現することです。この機能は、更新する要求で、クライアントがその資源は存在しないと信じている時に既存の資源を不注意に修正してしまうことを防ぐためにも使えます。
As a special case, the value "*" matches any current entity of the resource.
特別な場合として、値 * は資源の現在の実体に一致します。
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource, then the server MUST NOT perform the requested method, unless required to do so because the resource's modification date fails to match that supplied in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server SHOULD respond with a 304 (Not Modified) response, including the cache-related entity-header fields (particularly ETag) of one of the entities that matched. For all other request methods, the server MUST respond with a status of 412 (Precondition Failed).
実体札のいずれかが同様の (If-None-Match 頭なしの) GET 要求への応答で返されるであろう実体の実体札と一致するか、 または * が与えられ、その資源に現在の実体が存在するなら、資源の修正日付が要求の If-Modified-Since 頭欄で供給されたものと一致しなかったためにそうする必要がある場合を除き、 サーバーは要求された方式を処理してはなりません。 代わりに、要求方式が GET または HEAD であるなら、サーバーは、その一致する実体の一つのキャッシュ関連の頭欄 (特に ETag) を含めた 304 (未修正) 応答で応答するべきです。 他のすべての要求方式では、サーバーは 412 (前条件失敗) の状態で応答しなければなりません。
HEAD
ETag
304
See section 13.3.3 for rules on how to determine if two entity entities tags match. The weak comparison function can only be used with GET or HEAD requests.
二つの実体札の一致をどう決定するかの規則は13.3.3節を参照。 弱い比較関数は GET または HEAD の要求でのみ使うことができます。
If none of the entity tags match, or if "*" is given and no current entity exists, then the server MAY perform the requested method as if the If-None-Match header field did not exist, but MUST also ignore any If-Modified-Since header field(s) in the request. That is, if no entity tags match, then the server MUST NOT return a 304 (Not Modified) response.
実体札のいずれもが一致しなかったか、* が与えられ現在の実体が存在しないなら、 サーバーは要求された方式を If-None-Match 頭欄(群)が要求に存在しなかったものとしてその要求された方式を実行して構いませんが、要求にある If-Modified-Since 頭欄(群)も無視しなければなりません。つまり、実体札がどれも一致しなければ、サーバーは 304 (未修正) 応答を返さなければなりません。
If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the If-None-Match header MUST be ignored. (See section 13.3.4 for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
If-None-Match 頭欄がなければ要求の結果が 2xx 状態または 304 状態以外のものになるとしたら、 If-None-Match 頭は無視しなければなりません。(If-Modified-Since と If-None-Match の両方が同じ要求に現れる時のサーバーの振る舞いについての議論は13.3.4節を参照。)
The meaning of "If-None-Match: *" is that the method MUST NOT be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see section 14.43 14.44) exists, and SHOULD be performed if the representation does not exist. This feature may is intended to be useful in preventing races between PUT operations.
If-None-Match: * の意味は、その方式は起源サーバーによって (またはキャッシュによって、もしかすると Vary 機構を使って) 選択された表現が存在しないときに実行してはならず、表現が存在しないときには実行するべきだということです。 この機能は PUT 操作間の競合を防ぐのに有用であることを意図しています。
If-None-Match: "xyzzy"If-None-Match: W/"xyzzy"If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"If-None-Match: *
The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header fields is undefined by this specification.
If-None-Match 頭欄と If-Match 頭欄または If-Unmodified-Since 頭欄のいずれかを持っている要求の結果はこの仕様書では未定義とします。
If-Unmodified-Since
See [H14.25].
This field is especially useful for ensuring the integrity of the presentation description, in both the case where it is fetched via means external to RTSP (such as HTTP), or in the case where the server implementation is guaranteeing the integrity of the description between the time of the DESCRIBE message and the SETUP message.
[1] この欄は、表現記述の完全性を確認するのに、これが RTSP 以外の手段 (例えば HTTP) で入手した場合においても或いはサーバー実装が DESCRIBE メッセージの時刻及び SETUP メッセージ間の記述の正当性を保証する場合においても、特に有用です。
The identifier is an opaque identifier, and thus is not specific to any particular session description language.
[2] 識別子は不透明 (opaque) 識別子で、従ってどの特定の session 記述言語にも依存しません。
If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
[39] Overwrite: は If-Match: * と似ていますが、対象資源ではなく終点資源に適応される点が異なります。
Overwrite:
Conditional headers can be used to specify a pre-condition that determines whether the patch operation happens. The If-Match header specifies that the patch operation will succeed if and only if the ref value matches current stored ref. A failed If-Match patch-merge request will return a 412 Error "item_version_mismatch".
[44] RFC 4791 - Calendaring Extensions to WebDAV (CalDAV) (2017-09-24 16:22:36 +09:00) <https://tools.ietf.org/html/rfc4791#section-5.3.2>
If the If-Match: "<timestamp>" request header is provided as described in the section about timestamps, and if the list has changed meanwhile, a 412 Precondition Failed error is returned.
For cache and concurrency control, an ETag response header gives the value that consumers can provide in subsequent requests using If-Match and If-None-Match headers (see section about timestamps).
[47] Server timestamps — Kinto 8.1.5 documentation (2018-02-21 01:03:20 +09:00) <https://kinto.readthedocs.io/en/latest/api/1.x/timestamps.html>