[4] [[キャッシュ]]が[[応答メッセージ]]の複製を蓄積して以後の[[要求]]に答えるために使うことが認められている時、 その[[応答]]は[DFN[[RUBYB[キャッシュ[RUBY[可][か]][RUBY[能][のう]]]@en[cacheable]]]]であるといいます [SRC[>>3]]。 ;; [5] ただし[[キャッシュ可能]]であるからといっていつでもその[[応答]]を使いまわせるわけではなく、 [[要求]]が色々な条件を満たす必要があります。 [26] 本項では[[キャッシュ]]に[[蓄積]]された ([[キャッシュ項目]]に含まれる) [[応答]]を再利用する (類似した新しい[[要求]]への[[応答]]として使う) 条件についても扱います。 ;; [13] [[キャッシュ可能]]な[[応答]]であっても、[[キャッシュ]]がそれを[[蓄積]]し再利用することは義務ではありません。 [[キャッシュ不可能]]な[[応答]]を[[キャッシュ]]することは禁止されていますが、 [[キャッシュ可能]]な[[応答]]が[[キャッシュ]]されて再利用されるかどうかは、 実装方法、設定、ディスク容量その他色々な状況に依存します。 * 仕様書 [REFS[ - [3] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) - [6] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) - [9] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) - [14] [CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) -- [23] [CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) - [27] [CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) - [52] [CITE@en[RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching]] ([TIME[2014-09-11 10:19:59 +09:00]] 版) - [59] [CITE@en[RFC 2295 - Transparent Content Negotiation in HTTP]] ([TIME[2014-08-31 19:36:42 +09:00]] 版) - [65] [CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) - [67] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2014-12-04 10:25:09 +09:00]] 版) ]REFS] * キャッシュ可能メソッド [7] [[応答]]を[[キャッシュ]]して再利用できる[[メソッド]]のことを、 [DFN[[RUBYB[[[キャッシュ可能]]]@en[cacheable]]]]であるといいます [SRC[>>6]]。 [8] 次の[[メソッド]]は、[[キャッシュ可能]]です [SRC[>>6]]。 [FIG(list short)[ - [CODE(HTTP)@en[[[GET]]]] - [CODE(HTTP)@en[[[HEAD]]]] - [CODE(HTTP)@en[[[POST]]]] - [CODE(HTTP)@en[[[PATCH]]]] - [CODE(HTTP)@en[[[PROPFIND]]]] ]FIG] ;; [63] これらの[[状態符号]]でも、 [CODE(HTTP)@en[[[Cache-Control:]]]] などの条件によって[[キャッシュ]]できないことがあります。 * キャッシュ可能な応答の状態符号 [11] 次の[[状態符号]]の[[応答]]は[[キャッシュ可能]]です。 [FIG(short list)[ - [CODE(HTTP)[[[200]]]] - [CODE(HTTP)[[[203]]]] - [CODE(HTTP)[[[204]]]] - [CODE(HTTP)[[[206]]]] - [CODE(HTTP)[[[226]]]] - [CODE(HTTP)[[[300]]]] - [CODE(HTTP)[[[301]]]] - [CODE(HTTP)[[[308]]]] - [CODE(HTTP)[404]] - [CODE(HTTP)[405]] - [CODE(HTTP)[410]] - [CODE(HTTP)[414]] - [CODE(HTTP)[421]] - [CODE(HTTP)[451]] - [CODE(HTTP)[501]] ]FIG] ;; [12] これらの[[状態符号]]でも、 [CODE(HTTP)@en[[[Cache-Control:]]]] など他の条件により[[キャッシュ]]できないことがあります。 [10] 未知の[[状態符号]]の[[応答]]は、[[キャッシュ]]しては[['''なりません''']] [SRC[>>9]]。 ;; [62] >>61 の [[JSON]] ファイルに[[状態符号]]が[[キャッシュ可能]]かどうかの情報が含まれています。 [REFS[ - [61] [CITE@en[data-web-defs/http-status-codes.txt at master · manakai/data-web-defs]] ([TIME[2014-11-20 20:44:16 +09:00]] 版) ]REFS] * キャッシュ可能性の判定 [15] [[応答]]を[[蓄積]]しても構わないかどうかは、次のように決定します。 [FIG(steps)[ = [16] [[要求メソッド]]を[[キャッシュ]]が理解しないなら、 蓄積できません [SRC[>>14]]。ここで終わります。 = [17] [[要求メソッド]]が[[キャッシュ可能]]でないなら、 蓄積できません [SRC[>>14]]。ここで終わります。 = [18] [[応答]]の[[状態符号]]を[[キャッシュ]]が理解しないなら、 蓄積できません [SRC[>>14]]。ここで終わります。 = [68] [CODE(DOMi)@en[[[EventSource]]]] のための [[fetch]] であれば、 蓄積する[['''べきではありません''']] [SRC[>>67]]。ここで終わります。 = [19] [[要求]]の [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]に [CODE(HTTP)@en[[[no-store]]]] [[キャッシュ指示子]]があるなら、蓄積できません [SRC[>>14]]。ここで終わります。 = [66] [[応答]]の [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]に [CODE(HTTP)@en[[[no-store]]]] [[キャッシュ指示子]]があり [SRC[>>14]]、 [CODE(HTTP)@en[[[Cache-Control: im]]]] が適用されないなら [SRC[>>65]]、蓄積できません。ここで終わります。 = [22] [[共有キャッシュ]]の場合、 == [20] [[応答]]の [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]に[[引数]]なしの [SRC[>>52]] [CODE(HTTP)@en[[[private]]]] [[キャッシュ指示子]]があるなら、蓄積できません [SRC[>>14]]。ここで終わります。 == [34] [[応答]]の [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]に [CODE(HTTP)@en[[[public]]]] か [CODE(HTTP)@en[[[s-maxage]]]] の[[キャッシュ指示子]]があれば、蓄積できます [SRC[>>14, >>23]]。ここで終わります。 == [21] [[要求]]に [CODE(HTTP)@en[[[Authorization:]]]] [[ヘッダー]]があって [[応答]]の [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]に [CODE(HTTP)@en[[[must-revalidate]]]] [[キャッシュ指示子]]がなければ、 蓄積できません [SRC[>>14, >>23]]。ここで終わります。 = [35] [[応答]]が [CODE(HTTP)@en[[[Expires:]]]] [[ヘッダー]]を持つなら、蓄積できます [SRC[>>14]]。ここで終わります。 = [24] [[応答]]の [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]が [CODE(HTTP)@en[[[max-age]]]] か [CODE(HTTP)@en[[[public]]]] の[[キャッシュ指令]]を持つなら、蓄積できます [SRC[>>14]]。ここで終わります。 = [54] [[私的キャッシュ]]の場合、 == [53] [[応答]]の [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]が [CODE(HTTP)@en[[[private]]]] [[キャッシュ指令]]を持つなら、 [[蓄積]]できます [SRC[>>52]]。 = [25] [[応答]]が[[キャッシュ可能]]な[[状態符号]]を持つなら、蓄積できます [SRC[>>14]]。 ここで終わります。 = [31] 蓄積できません。 ]FIG] ;; [32] これらの条件は、将来新たに規定される[[キャッシュ指示子]]により上書きできます [SRC[>>14]]。 [33] ここで「理解」とは、認識しすべての[[キャッシュ]]に関係する動作を実装していることをいいます [SRC[>>14]]。 ;; [43] これは[[蓄積]]して良い条件であり、しなければならないわけではありません。 [[キャッシュ]]はより限定された条件でのみ[[蓄積]]して構いません。 [EG[ [44] 例えば[[キャッシュ]]はより簡易的に実装するために [CODE(HTTP)@en[[[Cache-Control:]] [[no-cache]]]] の[[応答]]を一切[[蓄積]]しないことにしても構いません。 (>>40 の[[検証]]の実装を省けます。) ;; [50] ただし [CODE(HTTP)[[[304]]]] [[応答]]によって[[ヘッダー]]が更新される場合 ([[条件付き要求]]参照。) があるなど、[[蓄積された応答]]が[[蓄積]]後に変更される可能性がありますから、 そのような[[蓄積された応答]]を破棄したり、無視したりする処理は[[検証]]のかわりに必要となります。 ]EG] ;; [56] [CODE(HTTP)@en[[[Proxy-Authorization:]]]] は[[キャッシュ可能性]]に影響しないようです。 [58] [[HTTP/0.9]] [[応答]]には[[状態符号]]を明示できないため、 [[キャッシュ不可能]]として扱うべきと思われます。 [64] [[差分符号化]]に関して、 [CODE(HTTP)@en[[[Cache-Control:]] [[retain]]]] の有無が[[キャッシュ]]を[[蓄積]]するべきかの[[ヒント]]を表しています。 ;; [CODE(HTTP)@en[[[retain]]]] を参照。 [69] [[OAuth 1.0]] で [CODE(HTTP)@en[[[Authorization:]]]] を使わない場合、 [[WSSE]]、その他独自の認証方式を使う場合には、 [[HTTPキャッシュ]]が[[キャッシュ可能]]と判断する条件を満たしてしまうことがよくあります。 そのような認証方式を使う[[クライアント]]や[[鯖]]は、 [CODE(HTTP)@en[[[Cache-Control:]]]] などで明示的に[[キャッシュ不可能]]と指定する必要があります。 * キャッシュの再利用 [28] [[キャッシュ]]は、次の条件をすべて満たす時に、 [[要求]]に対して[[キャッシュ項目]]の[[応答]]を再利用できます [SRC[>>27]]。 [FIG(list)[ - [29] [[実効要求URL]]が一致すること - [30] [[蓄積]]されている[[応答]]の[[要求メソッド]]が当該[[要求]]に再利用してよいこと - [36] [CODE(HTTP)@en[[[Vary:]]]] で指定された[[ヘッダー]]が一致すること - [37] 当該[[要求]]に [CODE(HTTP)@en[[[Cache-Control:]] [[no-cache]]]] や [CODE(HTTP)@en[[[Pragma:]] [[no-cache]]]] が含まれていないこと -- [38] ただし[[蓄積]]された[[応答]]の[[検証]]に成功した場合を除く - [39] [[蓄積]]されている[[応答]]に [CODE(HTTP)@en[[[Cache-Control:]] [[no-cache]]]] が含まれていないこと -- [40] ただし[[蓄積]]された[[応答]]の[[検証]]に成功した場合を除く - [41] [[蓄積]]されている[[応答]]が[[新鮮]]、[[腐敗]]していても提供することが認められている、 [[検証]]に成功したのいずれかであること ]FIG] [60] [[透過内容折衝に対応]]する[[キャッシュ]]は、[[リスト応答]]に関して [CODE(HTTP)@en[[[Vary:]]]] の条件を無視できます [SRC[>>59]] ([[リスト応答]]を参照)。 ;; [45] これらの条件は、新たな[[キャッシュ指示子]]により上書きできます [SRC[>>27]]。 [FIG(corollary)[ [47] [[安全]]でない[[メソッド]]の[[要求]]に[[キャッシュ]]が返答することはできず、 [[上流]]に[[転送]]しなければなりません。 ]FIG] [48] 候補が複数ある時は、最も新しいもの ([CODE(HTTP)@en[[[Date:]]]] が最新のもの) を使わなければ[['''なりません''']]。あるいは [CODE(HTTP)@en[[[Cache-Control:]] [[max-age]]=0]] または [CODE(HTTP)@en[[[Cache-Control:]] [[no-cache]]]] をつけて[[転送]]しても構いません。 [SRC[>>27]] ;; [[検証]]も参照。 [49] [[時計]]を持たない[[キャッシュ]]は、毎回[[検証]]しなければ[[蓄積]]された[[応答]]を使っては[['''なりません''']] [SRC[>>27]]。 ;; [42] これは再利用して良い条件であり、しなければならないわけではありません。 [[キャッシュ]]はより限定された条件でのみ再利用しても構いません。 ;; [46] 再利用については [CODE(HTTP)@en[[[Age:]]]] も参照。 ;; [51] [CODE(HTTP)@en[[[Cache-Control:]] [[max-age]], [[max-stale]], [[min-fresh]], [[must-revalidate]], [[proxy-revalidate]]]] も参照。 ;; [55] [[キャッシュ項目]]も参照。 ;; [57] ここでいう「再利用」は、 [CODE(HTTP)@en[[[Meter:]]]] [[ヘッダー]]の処理における 「利用」や「再利用」とは意味が異なります。 * 歴史 **HTTP/1.1 [2] [[RFC 2068]] は [DFN[[[cachable]]]] と綴っていましたが、 [[RFC 2616]] 以降は [DFN[[[cacheable]]]] とされています。 [FIG(quote)[ [FIGCAPTION[ [1] [[HTTP]] ([[RFC 2068]] 1.3, [[RFC 2616]] 1.3) ]FIGCAPTION] > :cach[INS[e]]able: A response is cach[INS[e]]able if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cach[INS[e]]ability of HTTP responses are defined in section 13. Even if a resource is cach[INS[e]]able, there may be additional constraints on whether a cache can use the cached copy for a particular request. :キャッシュ可能:[[応答]]は、[[キャッシュ]]が以後の[[要求]]に回答するのに使うためにその応答メッセージの複製を蓄積することが許されているなら、 [DFN[キャッシュ可能]]です。 HTTP 応答のキャッシュ可能性を決定する規則は13章で定義されています。 応答がキャッシュ可能であっても、特定の要求にキャッシュされた複製を使うことができるかどうかには更なる制約があるかもしれません。 ]FIG] [70] [CITE@en[Spelling of "cachable"]] ( ([[Jeffrey Mogul]]著, [TIME[1997-09-03 02:08:46 +09:00]])) *** 内容折衝 [71] [[内容折衝]]と[[キャッシュ]]との関係について。 [FIG(quote)[ [72] [[RFC 2068]]・[[RFC 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]]]] は既存の項目のものよりは新しい場合には、 その既存の項目は将来の要求に対する応答では返す'''べきではなく'''、 キャッシュから削除する'''べきです'''。 ]FIG] ** メモ