内容折衝//キャッシュ

内容折衝とキャッシュ (HTTP)

[1] 内容折衝キャッシュとの関係について。

仕様書から

RFC 2068・2616 (HTTP/1.1) 13.6 Caching Negotiated Responses

Use of server-driven content negotiation (section 12.1.1), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests. See section 14.44 for use of the Vary header field by servers.

サーバー駆動内容折衝の使用は応答Vary 頭欄の存在によって示されますが、 このときキャッシュが以後の要求にその応答を使用できる条件と手続きが変わります。

A server MUST SHOULD use the Vary header field (section 14.43) to inform a cache of what request-header fields dimensions are were used to select among multiple representations of a cacheable response subject to server-driven negotiation. A cache may use the selected representation (the entity included with that particular response) for replying to subsequent requests on that resource only when the subsequent requests have the same or equivalent values for all header fields specified in the Vary response-header. Requests with a different value for one or more of those header fields would be forwarded toward the origin server. The set of header fields named by the Vary field value is known as the "selecting" request-headers.

サーバーは、サーバー駆動折衝の対象となるキャッシュ可能な応答の複数の表現から選択するのにどの要求頭欄が使われるかをキャッシュに知らせるのに Vary 頭欄を使用しなければなりませんするべきですキャッシュは、その資源についての以後の要求に返答するのに、その以後の要求が Vary 応答頭欄に指定されたすべての頭欄で同じ又は同等の値を取っているときに限って選択された表現 (その特定の応答に含まれていた実体) を使っても構いません。幾つかの頭欄で異なる値を取っていた要求は起源サーバー転送されることになります。 Vary 欄値に名前の挙げられている頭欄の集合は「選択」要求頭と呼びます。

When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the new request match the corresponding stored request-headers in the original request.

キャッシュがその Request-URIVary 頭欄を含んだ1個か複数個のキャッシュ項目を示した以降の要求を受取った時には、 新しい要求にある選択要求頭の全てが対応する蓄積されている元の要求の要求頭欄に一致しない限り、そのキャッシュ項目を応答を構築するのに使ってはなりません

The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in section 4.2.

2つの要求の選択要求頭は、最初の要求の選択要求頭に、対応する BNF で認められている場所に線形空白 (LWS) を追加したり削除したりすること及び/又は4.2節のメッセージ頭についての規則にしたがって同じ欄名の複数のメッセージ頭欄を結合することによって2番目の要求の選択要求頭欄に変形することができるなら、 この場合に限って、一致すると定義します。

A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted by the origin server.

Vary 頭欄の値 * は、 常に一致に失敗し、その資源についての後続の要求は期限サーバーのみが適切に解釈することができます。

If the selecting request header fields for the cached entry do not match the selecting request header fields of the new request, then the cache MUST NOT use a cached entry to satisfy the request unless it first relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity to be used.

キャッシュ項目の選択要求頭欄が新しい要求の選択要求頭欄に一致しなかった場合、 キャッシュはまず新しい要求を起源サーバーに条件付要求で中継して、 どの実体を使用するべきかを示す実体札又は Content-Location を含んだ 304 (未修正) でサーバーが応答してこない限り、そのキャッシュ項目を後続の要求を満足させるために使ってはなりません

If an entity tag was assigned to the a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the Request-URI resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.

実体札キャッシュされた表現に割当てられていた場合、転送する要求は条件的であって、 その Request-URI 資源についての全てのキャッシュ項目の実体札を If-None-Match 頭欄に含めるべきです。 これはキャッシュが現在保持している実体の集合をサーバーに伝達し、 その項目のどれかが要求された実体に一致する場合には、 サーバーは 304 (未修正) 応答で ETag 頭を使ってどの項目が適当かキャッシュに教えることができます。 新しい応答の entity-tag が既存の項目の実体札と一致する場合には、 新しい応答を既存の項目の頭欄を更新するのに使うべきで、 その結果はクライアントに返さなければなりません

The Vary header field may also inform the cache that the representation was selected using criteria not limited to the request-headers; in this case, a cache MUST NOT use the response in a reply to a subsequent request unless the cache relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates which entity should be used.

Vary 頭欄は、要求頭欄に限定されない基準を使って表現を選択したことをキャッシュに知らせることもできます。 この場合、キャッシュは新しい要求を起源サーバーに条件付要求で中継して、 どの実体を使用するべきかを示す実体札又は Content-Location を含んだ 304 (未修正) でサーバーが応答してこない限り、その応答を後続の要求で使ってはなりません

If any of the existing cache entries contains only partial content for the associated entity, its entity-tag SHOULD NOT be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that entry.

既存のキャッシュ項目のどれかが関連付けられた実体の部分内容だけしか含んでいない時には、 その要求がその項目で完全に満足できる範囲である場合を除いて、 その項目の entity-tagIf-None-Match 頭欄に含めるべきではありません

If a cache receives a successful response whose Content-Location field matches that of an existing cache entry for the same Request-URI Request-]URI (ママ), whose entity-tag differs from that of the existing entry, and whose Date is more recent than that of the existing entry, the existing entry SHOULD NOT be returned in response to future requests, and should SHOULD be deleted from the cache.

キャッシュが成功応答を受取り、その Content-Location 欄が同じ Request-URI の既存のキャッシュ項目のものと一致し、 その entity-tag は既存の項目のものとは異なり、 その Date は既存の項目のものよりは新しい場合には、 その既存の項目は将来の要求に対する応答では返すべきではなく、 キャッシュから削除するべきです

RFC の部分の License

RFCのライセンス

メモ