キャッシュ再利用

Edit New

キャッシュ可能 (HTTP)

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

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

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

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

仕様書

キャッシュ可能メソッド

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

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

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

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

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

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

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

[62] >>61 の JSON ファイルに状態符号がキャッシュ可能かどうかの情報が含まれています。

キャッシュ可能性の判定

[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 キャッシュ指示子があり >>14、 Cache-Control: im が適用されないなら >>65、蓄積できません。ここで終わります。
  7. [22] 共有キャッシュの場合、
    1. [20] 応答の Cache-Control: ヘッダーに引数なしの >>52 private キャッシュ指示子があるなら、蓄積できません >>14。ここで終わります。
    2. [34] 応答の Cache-Control: ヘッダーに public か s-maxage のキャッシュ指示子があれば、蓄積できます >>14, >>23。ここで終わります。
    3. [21] 要求に Authorization: ヘッダーがあって 応答の Cache-Control: ヘッダーに must-revalidate キャッシュ指示子がなければ、 蓄積できません >>14, >>23。ここで終わります。
  8. [35] 応答が Expires: ヘッダーを持つなら、蓄積できます >>14。ここで終わります。
  9. [24] 応答の Cache-Control: ヘッダーが max-age か public のキャッシュ指令を持つなら、蓄積できます >>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.0 で Authorization: を使わない場合、 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: も参照。
[51] Cache-Control: max-age, max-stale, min-fresh, must-revalidate, proxy-revalidate も参照。
[55] キャッシュ項目も参照。
[57] ここでいう「再利用」は、 Meter: ヘッダーの処理における 「利用」や「再利用」とは意味が異なります。

歴史

[2] RFC 2068 は cachable と綴っていましたが、 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>

Updated: