キャッシュ再利用

キャッシュ可能 (HTTP)

[4] キャッシュ応答メッセージの複製を蓄積して以後の要求に答えるために使うことが認められている時、 その応答キャッシュ可能 (cacheable) であるといいます >>3

[5] ただしキャッシュ可能であるからといっていつでもその応答を使いまわせるわけではなく、 要求が色々な条件を満たす必要があります。

[26] 本項ではキャッシュ蓄積された (キャッシュ項目に含まれる) 応答を再利用する条件についても扱います。

[13] キャッシュ可能応答であっても、キャッシュがそれを蓄積し再利用することは義務ではありません。 キャッシュ不可能応答キャッシュすることは禁止されていますが、 キャッシュ可能応答キャッシュされて再利用されるかどうかは、 実装方法、設定、ディスク容量その他色々な状況に依存します。

仕様書

キャッシュ可能メソッド

[7] 応答キャッシュして再利用できるメソッドのことを、 キャッシュ可能 (cacheable) であるといいます >>6

[8] 次のメソッドは、キャッシュ可能です >>6

[63] これらの状態符号でも、 Cache-Control: などの条件によってキャッシュできないことがあります。

キャッシュ可能な応答の状態符号

[11] 次の状態符号応答キャッシュ可能です。

[12] これらの状態符号でも、 Cache-Control: など他の条件によりキャッシュできないことがあります。

[10] 未知の状態符号応答は、キャッシュしてはなりません >>9

キャッシュ可能性の判定

[15] 応答蓄積しても構わないかどうかは、次のように決定します。

  1. [16] 要求メソッドキャッシュが理解しないなら、 蓄積できません >>14。ここで終わります。
  2. [17] 要求メソッドキャッシュ可能でないなら、 蓄積できません >>14。ここで終わります。
  3. [18] 応答状態符号キャッシュが理解しないなら、 蓄積できません >>14。ここで終わります。
  4. [68] EventSource のための fetch であれば、 蓄積するべきではありません >>67。ここで終わります。
  5. [19] 要求Cache-Control: ヘッダーno-store キャッシュ指示子があるなら、蓄積できません >>14。ここで終わります。
  6. [66] 応答Cache-Control: ヘッダーno-store キャッシュ指示子があり >>14Cache-Control: im が適用されないなら >>65、蓄積できません。ここで終わります。
  7. [22] 共有キャッシュの場合、
    1. [20] 応答Cache-Control: ヘッダー引数なしの >>52 private キャッシュ指示子があるなら、蓄積できません >>14。ここで終わります。
    2. [34] 応答Cache-Control: ヘッダーpublics-maxageキャッシュ指示子があれば、蓄積できます >>14, >>23。ここで終わります。
    3. [21] 要求Authorization: ヘッダーがあって 応答Cache-Control: ヘッダーmust-revalidate キャッシュ指示子がなければ、 蓄積できません >>14, >>23。ここで終わります。
  8. [35] 応答Expires: ヘッダーを持つなら、蓄積できます >>14。ここで終わります。
  9. [24] 応答Cache-Control: ヘッダーmax-agepublicキャッシュ指令を持つなら、蓄積できます >>14。ここで終わります。
  10. [54] 私的キャッシュの場合、
    1. [53] 応答Cache-Control: ヘッダーprivate キャッシュ指令を持つなら、 蓄積できます >>52
  11. [25] 応答キャッシュ可能状態符号を持つなら、蓄積できます >>14。 ここで終わります。
  12. [31] 蓄積できません。

[32] これらの条件は、将来新たに規定されるキャッシュ指示子により上書きできます >>14

[33] ここで「理解」とは、認識しすべてのキャッシュに関係する動作を実装していることをいいます >>14

[43] これは蓄積して良い条件であり、しなければならないわけではありません。 キャッシュはより限定された条件でのみ蓄積して構いません。

[44] 例えばキャッシュはより簡易的に実装するために Cache-Control: no-cache応答を一切蓄積しないことにしても構いません。 (>>40検証の実装を省けます。)

[50] ただし 304 応答によってヘッダーが更新される場合 (条件付き要求参照。) があるなど、蓄積された応答蓄積後に変更される可能性がありますから、 そのような蓄積された応答を破棄したり、無視したりする処理は検証のかわりに必要となります。
[56] Proxy-Authorization:キャッシュ可能性に影響しないようです。

[58] HTTP/0.9 応答には状態符号を明示できないため、 キャッシュ不可能として扱うべきと思われます。

[64] 差分符号化に関して、 Cache-Control: retain の有無がキャッシュ蓄積するべきかのヒントを表しています。

retain を参照。

[69] OAuth 1.0Authorization: を使わない場合、 WSSE、その他独自の認証方式を使う場合には、 HTTPキャッシュキャッシュ可能と判断する条件を満たしてしまうことがよくあります。 そのような認証方式を使うクライアントは、 Cache-Control: などで明示的にキャッシュ不可能と指定する必要があります。

キャッシュの再利用

[28] キャッシュは、次の条件をすべて満たす時に、 要求に対してキャッシュ項目応答を再利用できます >>27

[60] 透過内容折衝に対応するキャッシュは、リスト応答に関して Vary: の条件を無視できます >>59 (リスト応答を参照)。

[45] これらの条件は、新たなキャッシュ指示子により上書きできます >>27

[47] 安全でないメソッド要求キャッシュが返答することはできず、 上流転送しなければなりません。

[48] 候補が複数ある時は、最も新しいもの (Date: が最新のもの) を使わなければなりません。あるいは Cache-Control: max-age=0 または Cache-Control: no-cache をつけて転送しても構いません。 >>27

検証も参照。

[49] 時計を持たないキャッシュは、毎回検証しなければ蓄積された応答を使ってはなりません >>27

[42] これは再利用して良い条件であり、しなければならないわけではありません。 キャッシュはより限定された条件でのみ再利用しても構いません。
[46] 再利用については Age: も参照。
[57] ここでいう「再利用」は、 Meter: ヘッダーの処理における 「利用」や「再利用」とは意味が異なります。

歴史

[2] RFC 2068cachable と綴っていましたが、 RFC 2616 以降は cacheable とされています。

[1] HTTP (RFC 2068 1.3, RFC 2616 1.3)
cacheable
A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request.
キャッシュ可能
応答は、キャッシュが以後の要求に回答するのに使うためにその応答メッセージの複製を蓄積することが許されているなら、 キャッシュ可能です。 HTTP 応答のキャッシュ可能性を決定する規則は13章で定義されています。 応答がキャッシュ可能であっても、特定の要求にキャッシュされた複製を使うことができるかどうかには更なる制約があるかもしれません。

[70] Spelling of "cachable" ( (Jeffrey Mogul著, )) <https://lists.w3.org/Archives/Public/ietf-http-wg-old/1997SepDec/0003.html>