store

キャッシュ項目 (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 応答 >>125266 応答 >>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時間を超えていて、応答警告符号 113Warning: ヘッダーがなければ、追加します (新鮮寿命参照)。
      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] 応答警告符号1xxWarning: ヘッダーがあれば、削除します >>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] 応答警告符号 110Warning: ヘッダーを追加します >>46, >>36
      2. [52] 意図的に切断されていた場合には、 応答警告符号 112Warning: ヘッダーを追加します >>49, >>36
      3. [57] 上流への接続に失敗した場合には、 応答警告符号 111Warning: ヘッダーを追加します >>43, >>36
  9. [59] 使う応答が「エラー応答」の場合、
    1. [70] 上流から不正な応答を受信して「エラー応答」に設定された場合、 新しい 502 応答応答とします >>121
    2. [18] それ以外の場合、新しい 504 応答応答とします >>104, >>101
  10. [37] 要求または応答Cache-Control: no-transform が含まれない場合で、変形を適用したい場合、
    1. [86] 変形を適用します >>85
    2. [35] 警告符号 214Warning: ヘッダーを (なければ) 追加します >>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 参照。