226

状態符号 226 (HTTP)

[18] 226 (IM Used) は、 payload に含まれるのが選択された表現実現値操作を適用した結果であることを示す状態符号です。

仕様書

意味

[7] 226 は、資源に対する GET 要求を満足し、応答が現在の実現値に1つ以上の実現値操作を適用した結果の表現であることを示す状態符号です。 >>6

構文

[12] 226 応答は現在の実現値実体タグETag: ヘッダーに指定しなければなりません >>6

[17] RFC 723x 世代の HTTP 仕様では 304206ヘッダーに関する制約がいくつかあります。 226 にはそのような制約はなく、仕様も更新されていませんが、 同等に扱うべきかもしれません。

[20] 範囲選択とそれ以外の実現値操作を適用した時は、その適用順序を IM: ヘッダーで明記しなければなりません >>6

文脈

[11] 元の要求A-IM: ヘッダーで最低1つは実現値操作を挙げたものでなければなりません >>6

[21] IM: が含まれる応答状態符号226 でなければなりません >>19

処理モデル

[8] 実際の現在の実現値は他の以前または以後の応答とこの応答実現値操作依存の方法で組み合わせないと得られないこともあります。 その場合には、結合した実現値ヘッダーは、 226ヘッダーと他の実現値ヘッダーを組み合わせたものです。 >>6

[9] RFC 3229 は当時の HTTP の規定を参照していますが、 RFC 723x 世代には直接それに相当する規定がなくなっています。 RFC 723x では 304範囲要求の場合でそれぞれ規定があります。

[13] 226 応答キャッシュ可能です >>6

[23] キャッシュは、受信した 226 応答実現値操作をすべて復号して元の実現値を含む状態符号 200 応答を復元し、蓄積して構いません。 このキャッシュ項目は通常のキャッシュの規則に従い利用しなければなりません>>22, >>6

[14] キャッシュは、受信した 226 応答実現値操作のうち範囲選択以外を復号して得た状態符号 206応答蓄積して構いません。 このキャッシュ項目は通常のキャッシュの規則に従い利用しなければなりません>>22

[24] キャッシュは、受信した 226 応答キャッシュ項目として蓄積して構いません >>22

[25] キャッシュは、状態符号226応答を次のいずれかの条件を満たす場合に再利用してはなりません >>22

[32] 内容符号化の処理については、内容符号化を参照。

文脈

[3] 差分符号化した応答は、状態符号226 としなければなりません >>2

差分符号化も参照。

[4] 差分符号化した応答IM: ヘッダーには使用した差分符号化を明記しなければなりません >>2

[5] 差分符号化した応答Digest-Base: ヘッダーによって基底実現値実体タグを示すことができます >>2

歴史

[15] RFC 3229 (差分符号化) 10.4.1 226 IM Used

The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. The actual current instance might not be available except by combining this response with other previous or future responses, as appropriate for the specific instance-manipulation(s). If so, the headers of the resulting instance are the result of combining the headers from the status-226 response and the other instances, following the rules in section 13.5.3 of the HTTP/1.1 specification [10].

鯖は、要求に対する GET 要求を満たし、 応答は一つ以上の実現値操作を現在実現値に適用した結果の表現です。実際の現在実現値は、特定の実現値操作(群)によって、 この応答と他の以前または将来に応答を結合することによってでないと入手可能でないかもしれません。 そうである場合、 HTTP/1.1 仕様書の13.5.3 節の規則に従って状態 226 応答と他の実現値からの頭群を結合した結果が結果の実現値の頭群です。

The request MUST have included an A-IM header field listing at least one instance-manipulation. The response MUST include an Etag header field giving the entity tag of the current instance.

要求は、最低一つの実現値操作を挙げた A-IM 頭欄を含んでいなければなりません。 応答は、現在実現値の実体札を与える Etag 頭欄を含んでいなければなりません

A response received with a status code of 226 MAY be stored by a cache and used in reply to a subsequent request, subject to the HTTP expiration mechanism and any Cache-Control headers, and to the requirements in section 10.6.

状態符号 226 で受信した応答は、 キャッシュに蓄積して、後の要求に対する返答で用いて構いません。 ただし、 HTTP 満期機構および Cache-Control

頭群ならびに 10.6 節の要件の対象となります。

A response received with a status code of 226 MAY be used by a cache, in conjunction with a cache entry for the base instance, to create a cache entry for the current instance.

状態符号 226 で受信した応答は キャッシュが基底実現値キャッシュ項目と併せて現在実現値のキャッシュ項目を作成するために使って構いません

[16] RFC 3229 (差分符号化) 10.6 Caching rules for 226 responses

When a client or proxy receives a 226 (IM Used) response, it MAY use this response to create a cache entry in three ways:

クライアントまたは226 (IM 使用中) 応答を受信した時は、 この応答を三つの方法でキャッシュ項目を作成するために使用して構いません

  • 1. It MAY decode all of the instance-manipulations to recover the original instance, and store that instance in the cache. In this case, the recovered instance is stored as a status-200 response, and MUST be used in accordance with the normal HTTP caching rules.
  • 2. It MAY decode all of the instance-manipulations except for range selection(s), and store the result in the cache. In this case, the result is stored as a status-206 response, and MUST be used in accordance with the normal HTTP caching rules for Partial Content.
  • 3. It MAY store the status-226 (IM Used) response as a cache entry.
  • もとの実現値を回復するためにすべての実現値操作を復号して、 その実現値をキャッシュに蓄積して構いません。 この場合、回復した実現値は状態 200 応答として蓄積し、通常の HTTP キャッシュ付け規則に従って使用しなければなりません
  • 範囲選択(群)を除く実現値操作をすべて復号し、結果をキャッシュに蓄積して構いません。この場合、結果は状態 206 応答として蓄積し、部分内容についての通常の HTTP キャッシュ付け規則に従って使用しなければなりません
  • 状態 226 (IM 使用中) 応答をキャッシュ項目として蓄積して構いません

A status-226 cache entry MUST NOT be used in response to a subsequent request under any of these conditions (a cache that never stores status-226 responses may ignore these tests):

状態 226 キャッシュ項目は次のどの条件の下でも以後の要求に対する応答として使用してはなりません (状態 226 応答を蓄積しないキャッシュはこれらの試験を無視して構いません)。

  • 1. If any of the instance-manipulation values from the IM header field in the cached response do not appear in the subsequent request's A-IM header field. The comparison between the headers is done using an exact match on each instance-manipulation value including any associated imparams values see section 10.1).
  • 2. If the order of instance-manipulation values appearing in the cached IM header field differs from the order of that set of instance-manipulations in the A-IM header field of the subsequent request.
  • 3. If the cache implementation is not aware of, or is not at least conditionally compliant with, the specification of any of the instance-manipulation values in the cached IM header field.
  • キャッシュした応答の IM 頭欄の実現値操作値のいずれもが後の要求の A-IM 頭欄に出現しない場合。 頭の比較は関連付けられた imparams 値を含めた各実現値操作値の正確一致を使って行います。
  • キャッシュした IM 頭欄の実現値操作値の順序が後の要求の A-IM 頭欄中の実現値操作の集合の順序と異なる場合。
  • キャッシュ実装がキャッシュした IM 頭欄中の実現値操作値のいずれかの仕様も知らないか、または最低でも条件的に適合していない場合。

Note: This rule allows for extending the set of instance-manipulations without causing deployed cache implementations to commit errors. The specification of new instance-manipulations may include additional caching rules to improve cache-hit rates in cognizant implementations.

注意: この規則により、実現値操作の集合を拡張しても既存のキャッシュ実装が誤りを起こすことはありません。 新しい実現値操作の仕様書は知っている実装のキャッシュ打率を向上する追加のキャッシュ付け規則を含むかもしれません。

  • 4. If any of the instance-manipulation values in the cached IM header field is a delta-coding, and the cache entry includes a Delta-Base header field, and that Delta-Base entity tag is not one of the entity tags listed in an If-None-Match header field of the subsequent request.
  • 5. If any of the instance-manipulation values in the cached IM header field is a delta-coding, the cache entry does not include a Delta-Base header field, and the If-None-Match header field of the request that led to that cache entry does not match the If-None-Match header field of the subsequent request.
  • キャッシュしている IM 頭欄の実現値操作値のいずれかが差分符号化であり、キャッシュ項目が Delta-Base 頭欄を含み、その Delta-Base 実体札後続要求If-None-Match 頭欄に列せられた実体札のいずれでもない場合。
  • キャッシュしている IM 頭欄の実現値操作値のいずれかが差分符号化であり、キャッシュ項目が Delta-Base 頭欄を含まず、そのキャッシュ項目に導いた要求の If-None-Match 頭欄が後続要求の If-None-Match 頭欄に一致しない場合。

If the IM header field of the cached response includes the "range" instance-manipulation, then a status-226 cache entry MUST NOT be used in response to a subsequent request if the cached response is inconsistent with the Range header field value(s) in the request, as would be the case for a cached 206 (Partial Content) response.

キャッシュしている応答の IM 頭欄が range 実現値操作を含む場合、 キャッシュ応答が要求の Range 頭欄値 (群) と不整合であるなら、キャッシュされた 206 (部分内容) 応答の場合と同様に、状態 226 キャッシュ項目を後続要求に対する応答に用いてはなりません

Note: we know of no existing, published formal specification for deciding if a cached status-206 response is consistent with a subsequent request. We believe that either of these conditions is sufficient:

注意: キャッシュされた状態 206 応答が後続要求に整合しているかどうかを決定する出版済み公式仕様書の存在は知られていません。 次の条件のいずれかが十分であると信じています。

  • 1. The ranges specified in the headers of the request that led to the cached response are the same as specified in the headers of the subsequent request.
  • 2. The ranges specified in the cached response are the same as specified in the headers of the subsequent request.
  • キャッシュ応答を導いた要求の頭群に指定された範囲が後続要求の頭群に指定されたものと同じである。
  • キャッシュ応答に指定された範囲が後続要求の頭群に指定されたものと同じである。

Further analysis might be necessary.

更なる調査が必要かもしれません。