キャッシュエントリー

Edit New

キャッシュ項目 (HTTP)

[2] キャッシュに蓄積されるデータの単位をキャッシュ項目 (cache entry) といいます。

仕様書

構成

[3] キャッシュ項目は、キャッシュキー (cache key) と、 1つ以上の HTTP応答との組です >>1。この応答のことを蓄積された応答 (stored response) といいます。

[9] 蓄積された応答には腐敗したものと新鮮なものがあり、また満期時刻や齢のような特性もあります。

[6] キャッシュ項目には、完全なものと不完全なものがあります。

[7] 不完全かどうかはメッセージの性質なので、正確にはキャッシュ項目ではなくキャッシュ項目に含まれる応答それぞれの性質だと思うのですが、 仕様上キャッシュ項目の性質となっています。

[172] Meter を実装する串の場合、 蓄積された応答について計測数に関するいくつかの値を保持する必要があります。

Meter 参照。

[4] キャッシュキーは要求メソッドと対象URLです。 しかし一般的なHTTPキャッシュは GET に対する応答しかキャッシュしないので、 その場合は対象URLだけをキャッシュキーとすることができます。 >>1

[5] 対象資源で内容折衝が使われている場合には、 複数のHTTP応答が蓄積されることになります。 >>1

[176] 蓄積された応答を利用できるかどうかの判定には、蓄積された応答のもととなった要求の情報の一部が必要になります。

[184] /.well-known/http-opportunistic を使う場合、 代替サービスの認証済み接続で得たものか否かのフラグを保持する必要があります。

処理

[8] キャッシュ可能性、検証、条件付き要求、部分要求も参照。

[10] キャッシュからの応答の決定は、次のように行います。

  1. [12] エラーその他の応答を返す場合、 HTTP認証によりエラーを返す場合などは、 そちらの方法で処理し、ここで終わります。
  2. [32] 使う応答を「上流の応答」とします。
  3. [24] キャッシュ項目として蓄積された応答から実効要求URLが一致するものがあれば >>23、
    1. [25] Vary: ヘッダーの条件が一致するもの (Vary: 参照。) のみに限定します >>23。
    2. [26] 蓄積された応答の要求メソッドが現在の要求の要求メソッドに再利用できるものに限定します >>23。
    3. [126] 現在の要求が求めている範囲をカバーできない不完全な応答や 206 応答 >>125、 266 応答 >>177 は除外します。
    4. [178] 266 応答の場合、その再利用の制限を満たさないものは除外します >>177。
    5. [27] 候補が複数ある場合は、次のいずれかとします >>23。
      • [29] Date: が最新のものを選びます。
      • [28] 使う応答を「無キャッシュの上流の応答」とします。
    6. [30] ここで、候補が1つの場合は、
      1. [89] 候補の複製を応答とします。
      2. [90] 使う応答を「キャッシュ応答」とします。
  4. [31] 使う応答が「キャッシュ応答」の場合、
    1. [69] 時計がない場合、検証必要フラグを設定します >>23。
    2. [13] それ以外の場合、
      1. [19] 齢を計算し、その結果を応答に Age: ヘッダーとして追加 (既にあれば置換) します (齢参照)。
      2. [14] 明示的満期時刻がある場合、これを使って新鮮寿命を決定します。
      3. [15] そうでない場合、
        1. [16] 発見的満期時刻を使って新鮮寿命を決定します。
        2. [17] 新鮮寿命が24時間を超えていて、応答に警告符号 113 の Warning: ヘッダーがなければ、追加します (新鮮寿命参照)。
      4. [20] 次のいずれかを満たす場合には、検証必要フラグを設定します。
  5. [47] 検証必要フラグが設定されている場合、
    1. [97] 要求に Cache-Control: only-if-cached があれば、使う応答を「エラー応答」とします >>93, >>38。
    2. [91] それ以外の場合、
      1. [108] 要求の複製を転送要求とします。
      2. [142] 要求のプロトコルの版を自身が対応する最高の版に書き換えます >>136。 版の変更による書き換えが必要なら、適宜行います。
      3. [145] ヘッダー名と : の間に空白があれば、除去します >>139。
      4. [146] obs-fold があれば置換します >>139。
      5. [160] Transfer-Encoding:, Content-Length:, Connection:, Via:, X-Forwarded-*:, Forwarded:, Host:, Proxy-Authorization:, TE:, Max-Forwards:, Meter:, RFC 2774 各ヘッダーや要求対象のホスト部分に関する書き換えを適宜行います (それぞれの項を参照)。
      6. [128] 応答に ETag: が含まれていれば、 If-None-Match: か If-Match: にその実体タグを指定します >>127。
      7. [109] 応答に Last-Modified: が含まれていれば、
        1. [130] 範囲要求で応答が HTTP/1.0 なら、 If-Unmodified-Since: に Last-Modified: の値を設定します >>106。
        2. [129] それ以外なら、 If-Modified-Since: に Last-Modified: の値を設定します >>106。
      8. [115] 転送要求を上流に転送します。
      9. [167] 応答に Cache-Control: stale-while-revalidate があってその秒数と新鮮寿命の和より齢が大きくないなら、 上流からの応答がなかったものとして先に進むと共に、 並列に上流からの最終的な応答を待ち、受信した時の処理(のみ)を行います >>166。
      10. [98] 上流からの最終的な応答を受信したら、
        1. [122] 不正な応答なら、応答を得られなかったとします。
        2. [116] 304 応答なら、
          1. [164] 蓄積された応答を更新します >>106 (条件付き要求参照)。
          2. [165] 元の要求が条件付き要求だった場合を除き >>163、 更新結果を上流からの応答とします >>106, >>107。
        3. [117] 5xx 応答なら、応答を得られなかったとして構いません >>107。
      11. [118] 上流からの応答がある場合、
        1. [132] 時計があり、上流からの応答に Date: がないなら、 Date: ヘッダーを追加します >>131。
        2. [119] 上流からの応答がキャッシュ可能で要求によって禁止されていないなら、 蓄積された応答を上流からの応答により置換して構いません >>107。
        3. [120] 上流からの応答を応答とします >>107。
        4. [100] 使う応答を「検証済み応答」に設定します。
        5. [105] 応答に警告符号が 1xx の Warning: ヘッダーがあれば、削除します >>96。
      12. [21] それ以外の場合、
        1. [58] 次のいずれかを満たす場合には、使う応答を「エラー応答」に設定します。
        2. [40] それ以外で、要求に Cache-Control: max-stale が指定されている場合、
          1. [42] 値が指定されている場合、齢と新鮮寿命の差が指定された値以下なら、 使う応答を「腐敗応答」に設定します >>50。 それ以外なら、使う応答を「エラー応答」に設定します。
          2. [44] 値が指定されていない場合、使う応答を「腐敗応答」に設定します >>50。
        3. [41] そうでない場合、
          1. [55] 要求に Cache-Control: max-age が指定されていない場合 >>54、
            1. [169] 使う応答を「腐敗応答」に設定します。
          2. [170] それ以外なら、
            1. [171] 要求または応答またはその両方に Cache-Control: state-if-error があり、 いずれもその秒数と新鮮寿命の和より齢が大きくないなら、 使う応答を「腐敗応答」に設定します >>168。
            2. [173] それ以外なら、使う応答を「エラー応答」に設定します。
          3. [51] それ以外の場合、使う応答を「腐敗応答」に設定します。
  6. [67] 使う応答が「上流の応答」または「無キャッシュ上流の応答」の場合、
    1. [92] 要求に Cache-Control: only-if-cached があれば、使う応答を「エラー応答」とします >>93, >>38。
    2. [94] それ以外の場合、
      1. [68] 転送要求を要求の複製とします。
      2. [147] 要求のプロトコルの版を自身が対応する最高の版に書き換えます >>136。 版の変更による書き換えが必要なら、適宜行います。
      3. [148] ヘッダー名と : の間に空白があれば、除去します >>139。
      4. [149] obs-fold があれば置換します >>139。
      5. [150] Transfer-Encoding:, Content-Length:, Connection:, Via:, Host:, Proxy-Authorization:, TE:, Max-Forwards:, X-Forwarded-*:, Forwarded:, Meter:, RFC 2774 各ヘッダーや要求対象のホスト部分に関する書き換えを適宜行います (それぞれの項を参照)。
      6. [88] 使う応答が「無キャッシュ上流の応答」なら、転送要求に Cache-Control: max-age=0 または Cache-Control: no-cache を追加します >>23。
      7. [65] 転送要求を要求として上流に送信します。
      8. [153] 1xx 応答を受信したら、それぞれについて、
        1. [154] 不正な応答の場合、使う応答を「エラー応答」に設定します。
        2. [155] それ以外の場合、
          1. [156] 時計があり、上流からの応答に Date: がないなら、 Date: ヘッダーを追加します >>131。
          2. [157] 要求のプロトコルの版を自身が対応する最高の版に書き換えます >>136。 版の変更による書き換えが必要なら、適宜行います。
          3. [158] ヘッダー名と : の間に空白があれば、除去します >>139。
          4. [159] obs-fold があれば置換します >>139。
          5. [161] Transfer-Encoding:, Content-Length:, Connection:, Via:, Meter:, RFC 2774 各ヘッダーに関する書き換えを適宜行います (それぞれの項を参照)。
          6. [162] 下流に送信します。
      9. [66] 上流からの最終的な応答を受信したら、
        1. [123] 不正な応答の場合、使う応答を「エラー応答」に設定します。
        2. [124] それ以外の場合、
          1. [135] 時計があり、上流からの応答に Date: がないなら、 Date: ヘッダーを追加します >>131。
          2. [134] 上流からの応答がキャッシュ可能で要求によって禁止されていないなら、 蓄積された応答を更新したり、新規に蓄積したりして構いません。
          3. [133] 上流からの応答を応答に設定します。
      10. [33] 受信できなかった場合は、使う応答を「エラー応答」に設定します。
  7. [34] 使う応答が「上流の応答」か「検証済み応答」の場合、
    1. [137] 応答のプロトコルの版を、要求と自身が対応する最高の版に書き換えます >>136。 版の変更による書き換えが必要なら、適宜行います。
    2. [140] ヘッダー名と : の間に空白があれば、除去します >>139。
    3. [143] obs-fold があれば置換します >>139。
    4. [151] Transfer-Encoding:, Content-Length:, Connection:, Via:, Meter:, RFC 2774 各ヘッダーに関する書き換えを適宜行います (それぞれの項を参照)。
  8. [79] 使う応答が「キャッシュ応答」または「腐敗応答」の場合、
    1. [138] 応答のプロトコルの版を、要求と自身が対応する最高の版に書き換えます >>136。 版の変更による書き換えが必要なら、適宜行います。
    2. [141] ヘッダー名と : の間に空白があれば、除去します >>139。
    3. [144] obs-fold があれば置換します >>139。
    4. [152] Transfer-Encoding:, Content-Length:, Connection:, Via:, Meter:, RFC 2774 各ヘッダーに関する書き換えを適宜行います (それぞれの項を参照)。
    5. [76] 応答に Cache-Control: no-cache があって、 ヘッダー名が指定されている場合、
      1. [77] 応答から指定されているヘッダーをすべて削除します >>73。
    6. [56] 使う応答が「腐敗応答」の場合、
      1. [45] 応答に警告符号 110 の Warning: ヘッダーを追加します >>46, >>36。
      2. [52] 意図的に切断されていた場合には、 応答に警告符号 112 の Warning: ヘッダーを追加します >>49, >>36。
      3. [57] 上流への接続に失敗した場合には、 応答に警告符号 111 の Warning: ヘッダーを追加します >>43, >>36。
  9. [59] 使う応答が「エラー応答」の場合、
    1. [70] 上流から不正な応答を受信して「エラー応答」に設定された場合、 新しい 502 応答を応答とします >>121。
    2. [18] それ以外の場合、新しい 504 応答を応答とします >>104, >>101。
  10. [37] 要求または応答に Cache-Control: no-transform が含まれない場合で、変形を適用したい場合、
    1. [86] 変形を適用します >>85。
    2. [35] 警告符号 214 の Warning: ヘッダーを (なければ) 追加します >>85。
    3. [87] 状態符号が 200 なら、 203 に変更しても構いません >>85。
  11. [99] エラーの応答やリダイレクトの応答の場合、 それを返してここで終わります。 >>18
  12. [11] 使う応答が「キャッシュ応答」または「腐敗応答」なら、 要求に事前条件があれば適用します。真なら、あるいは事前条件がなければ、 応答を返します。詳しくは条件付き要求を参照。
[48] このアルゴリズムは HTTP 仕様書に含まれる要件をできるだけ矛盾なく満たそうと試みたものです。 HTTP 仕様書には曖昧な記述や境界での動作が不明瞭なケース、 機能同士の相互作用が明確に規定されていないケースが多く、 細部においてこのアルゴリズムが正しいか (あるいは仕様上必ずしも要求されていないことまで求めていないか) 判断することは困難です。 また仕様上なぜか推奨や事実の文に留まっていて要件となっていない箇所などもあります。 詳しくは関連各項も参照してください。

キャッシュの非妥当化

[187] 非妥当化参照。

キャッシュ項目の削除

[179] キャッシュ項目を削除するタイミングについて、仕様上は規定はありません。 腐敗したキャッシュ項目はただちに応答として再利用することはできなくなりますが、 再検証すれば再利用できますから、必ずしも削除しなくても構いません。

[180] キャッシュは、ストレージ容量その他の都合で任意のタイミングでキャッシュ項目を削除できます。

[183] キャッシュは、同じ対象資源や Vary: の新しい応答を蓄積するときに、前のキャッシュ項目を削除したり、置き換えたりできます。

[182] 応答の Cache-Control: retain キャッシュ指令でのデルタ秒の指定は、 指定された秒数が経過した後キャッシュ項目を削除できます。

retain はヒントであり、それより前に削除しても構いませんし、 それより後まで削除しなくても構いません。

[181] キャッシュ項目全体、またはキャッシュ項目に関連付けられた計測数を削除する場合には、 計測数を報告しなければならないことがあります。

Meter 参照。
Updated: