#?SuikaWiki/0.9 [1] [[内容折衝]]と[[キャッシュ]]との関係について。 [[#comment]] * 仕様書から ** RFC 2068・2616 (HTTP/1.1) 13.6 Caching Negotiated Responses > Use of server-driven content negotiation (section 12.1[INS[.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. [INS[See section 14.44 for use of the Vary header field by servers.]] サーバー駆動内容折衝の使用は[[応答]]の [CODE(HTTP)[[[Vary]]]] 頭欄の存在によって示されますが、 このときキャッシュが以後の[[要求]]にその応答を使用できる条件と手続きが変わります。 > A server [DEL[MUST]] [INS[SHOULD]] use the Vary header field [DEL[(section 14.43)]] to inform a cache of what [INS[request-]]header field[INS[s]] [DEL[dimensions]] [DEL[are]] [INS[were]] used to select among multiple representations of a cacheable response [INS[subject to server-driven negotiation]]. [DEL[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.]] [INS[The set of header fields named by the Vary field value is known as the "selecting" request-headers.]] サーバーは、[INS[[[サーバー駆動折衝]]の対象となる]][[キャッシュ可能]]な応答の複数の表現から選択するのにどの[[要求頭欄]]が使われるかを[[キャッシュ]]に知らせるのに [CODE(HTTP)[[[Vary]]]] 頭欄を使用[DEL[しなければなりません]][INS[するべきです]]。 [DEL[キャッシュは、その資源についての以後の要求に返答するのに、その以後の要求が [CODE(HTTP)[Vary]] 応答頭欄に指定されたすべての頭欄で同じ又は同等の値を取っているときに限って選択された表現 (その特定の応答に含まれていた[[実体]]) を使っても構いません。幾つかの頭欄で異なる値を取っていた要求は[[起源サーバー]]に[[転送]]されることになります。]] [INS[[CODE(HTTP)[Vary]] 欄値に名前の挙げられている頭欄の集合は[DFN[「選択」要求頭]]と呼びます。]] [INS[ > 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. キャッシュがその [CODE(ABNF)[[[Request-URI]]]] が [CODE(HTTP)[Vary]] 頭欄を含んだ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番目の要求の選択要求頭欄に変形することができるなら、 この場合に限って、[DFN[一致する]]と定義します。 > 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. [CODE(HTTP)[Vary]] 頭欄の値 [CODE(HTTP)[*]] は、 常に一致に失敗し、その資源についての後続の要求は期限サーバーのみが適切に解釈することができます。 > 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. キャッシュ項目の選択要求頭欄が新しい要求の選択要求頭欄に一致しなかった場合、 キャッシュはまず新しい要求を起源サーバーに条件付要求で中継して、 どの実体を使用するべきかを示す実体札又は [CODE(HTTP)[Content-Location]] を含んだ [CODE(HTTP)[304]] (未修正) でサーバーが応答してこない限り、そのキャッシュ項目を後続の要求を満足させるために使っては'''なりません'''。 ]INS] > If an entity tag was assigned to [DEL[the]] [INS[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 [DEL[Request-URI]] [INS[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. [[実体札]]が[INS[キャッシュされた]]表現に割当てられていた場合、転送する要求は[[条件的]]であって、 その [DEL[[CODE(ABNF)[Request-URI]]]] [INS[資源]]についての全てのキャッシュ項目の実体札を [CODE(HTTP)[[[If-None-Match]]]] 頭欄に含める'''べきです'''。 これはキャッシュが現在保持している実体の集合をサーバーに伝達し、 その項目のどれかが要求された実体に一致する場合には、 サーバーは [CODE(HTTP)[[[304]]]] (未修正) 応答で [CODE(HTTP)[[[ETag]]]] 頭を使ってどの項目が適当かキャッシュに教えることができます。 新しい応答の [CODE(ABNF)[[[entity-tag]]]] が既存の項目の実体札と一致する場合には、 新しい応答を既存の項目の頭欄を更新するのに使う'''べき'''で、 その結果はクライアントに返さなければ'''なりません'''。 [DEL[ > 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. [CODE(HTTP)[Vary]] 頭欄は、要求頭欄に限定されない基準を使って表現を選択したことをキャッシュに知らせることもできます。 この場合、キャッシュは新しい要求を起源サーバーに条件付要求で中継して、 どの実体を使用するべきかを示す実体札又は [CODE(HTTP)[[[Content-Location]]]] を含んだ [CODE(HTTP)[304]] (未修正) でサーバーが応答してこない限り、その応答を後続の要求で使っては'''なりません'''。 ]DEL] > 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 [INS[field]] unless the request is for a range that would be fully satisfied by that entry. 既存のキャッシュ項目のどれかが関連付けられた実体の[[部分内容]]だけしか含んでいない時には、 その要求がその項目で完全に満足できる範囲である場合を除いて、 その項目の [CODE(ABNF)[entity-tag]] を [CODE(HTTP)[If-None-Match]] 頭欄に含める'''べきではありません'''。 > If a cache receives a successful response whose Content-Location field matches that of an existing cache entry for the same [DEL[Request-URI]] [INS[Request-]URI]] [INS[(ママ)]], 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[DEL[,]] and [DEL[should]] [INS[SHOULD]] be deleted from the cache. キャッシュが成功応答を受取り、その [CODE(HTTP)[Content-Location]] 欄が同じ [CODE(ABNF)[Request-URI]] の既存のキャッシュ項目のものと一致し、 その [CODE(ABNF)[entity-tag]] は既存の項目のものとは異なり、 その [CODE(HTTP)[[[Date]]]] は既存の項目のものよりは新しい場合には、 その既存の項目は将来の要求に対する応答では返す'''べきではなく'''、 キャッシュから削除する'''べきです'''。 ** RFC の部分の License [[RFCのライセンス]] * メモ