[8] キャッシュが有効であるとただちに確認できる期限を満期時刻expiration timeといいます。 満期時刻までの時間を新鮮寿命freshness lifetimeといいます。新鮮寿命を過ぎていない応答を新鮮応答freshness response、 過ぎている応答を腐敗応答stale responseといいます。

仕様書

満期時刻

[27] 明示的満期時刻explicit expiration timeは、 キャッシュがそれ以降は蓄積された応答を検証なしで利用できなくなると起源鯖が意図する時刻です >>2。

明示的満期時刻は Expires: ヘッダーや Cache-Control: ヘッダーの max-age 指示子で指定できます。

[29] 通常は起源鯖は表現がそれまでは意味的に大きく変わらないだろうという将来の明示的満期時刻を指定しますが、 要求があるたびにキャッシュに検証させたい時は過去の明示的満期時刻を指定することもできます >>2。

[28] 発見的満期時刻heuristic expiration timeは、 明示的満期時刻が利用できない (鯖が指定していない) ときにキャッシュが割り当てるものです >>2。 明示的満期時刻がある場合、発見的満期時刻を使ってはなりません >>19。

[20] 発見的満期時刻を決定する方法は HTTP 仕様としては特に規定されていません >>19。また発見的方法を使うことも必須ではありません。使わない場合は、 明示されていない限り腐敗とみなすことになります。

[21] 応答が Last-Modified: ヘッダーを持つ場合、 その時刻からの時間間隔の何割か分を超えないような発見的な値を使うことが推奨encourageされています。典型的な割合は10%です。 >>19

[17] 満期でもただちに蓄積された応答を破棄する必要はありません。 キャッシュが検証を実装していれば、満期後の応答 (腐敗応答) を検証して有効であれば応答として再利用できます。

[43] 明示的満期時刻の有無は、 POST 要求や PATCH 要求 >>42 に対する応答のキャッシュ可能性に影響します。

新鮮寿命

[6] 応答の新鮮寿命freshness lifetimeは、 応答の起源鯖における生成と満期時刻までの間の時間です。

[10] 新鮮寿命は次のように決定します >>9。

  1. [18] 明示的満期時刻があれば、それまでの時間を次のようにして決定します。
    1. [11] 共有キャッシュであり、 Cache-Control: s-maxage が応答に含まれるなら、その値を返し、ここで終わります。
    2. [12] Cache-Control: max-age が応答に含まれるなら、 その値を返し、ここで終わります。
    3. [13] Expires: ヘッダーが応答に含まれるなら、 Expires: の値から Date: の値を引いた結果を返し、ここで終わります。
  2. [14] 発見的満期時刻までの時間を返します。

[15] 決定時に使う Cache-Control: 指令や Expires: が複数ある場合は、値は非妥当とみなします。 その場合腐敗とみなすことが推奨encouragedされています。 >>9

[37] Expires: の値が非妥当な時も、 過去の時刻、すなわち腐敗とみなすことになっています (Expires: 参照)。

[38] Date: が非妥当な時については明記されていませんが、 やはり非妥当で腐敗とみなすべきでしょう。

[39] Date: が存在しない時は、キャッシュ時に付与することになっています (Date: 参照)。

[41] 要求の Cache-Control: max-age で指定された値は満期時刻の決定に寄与しないようですが、応答が検証なしで返されるかどうかには影響します。

max-age 参照。

新鮮応答と腐敗応答

[3] 新鮮応答fresh responseは、 齢が新鮮寿命をまだ超えていない応答です >>2。

[4] 腐敗応答stale responseは、 齢が新鮮寿命を超えた応答です >>2。

[7] 新鮮か腐敗かは、キャッシュ操作にのみ適用されるものです。 利用者エージェントは腐敗していても表示し続けて何ら問題ありません。 >>2

非妥当化

[32] 蓄積された応答は非妥当化invalidateされることがあります。 これは蓄積された応答を削除するか、または「非妥当」フラグを立てるかのいずれかを意味しています >>33。蓄積された応答は、 HEAD 要求 >>34 や非安全要求メソッド >>33 に対する応答により非妥当化されます (詳細はそれぞれの項を参照)。 非妥当な場合は蓄積された応答を利用する前に検証が必要であり >>33、 「腐敗とする」 >>34 とも表現されています。

[184] DELETE メソッドはキャッシュを非妥当化します。

DELETE 参照。

[186] PATCH 要求の対象URLに関するキャッシュ項目は、 腐敗したものとして扱うべきです >>42。

転送

[22] キャッシュは、新鮮寿命の計算に発見的満期時刻を使った場合は >>40, >>19、 その新鮮寿命が24時間よりも大きな場合 >>40、 齢 (current_age) が24時間よりも大きければ >>40, >>19、 警告符号 113 の Warning: ヘッダーを (既に無ければ >>19) 生成するべきです >>40, >>19。

[24] キャッシュは、明示的に禁止された場合 (例えば no-store, no-cache, must-revalidate, s-maxage, proxy-revalidate が適用される場合) には、 腐敗応答を生成してはなりません >>23。

[25] キャッシュは、起源鯖と接続できないなど“切断されている”場合や max-stale などで明示的に認められている場合を除き、 腐敗応答を送ってはなりません >>23。

[26] キャッシュは、腐敗応答に警告符号 110 の Warning: ヘッダーを生成するべきです >>23。 111 を生成するべき場合もあります。

110, 111 も参照。

[30] キャッシュは、キャッシュが“切断されている”場合の腐敗応答に警告符号 112 の Warning: ヘッダーを生成するべきです >>23。

[31] キャッシュは、 Age: ヘッダーを持たない応答を転送する場合には、 Warning: ヘッダーを新たに生成するべきではありません。 キャッシュは転送中に腐敗した応答を検証する必要はありません。 >>23

[36] min-fresh が指定されている場合は、 新鮮であってもそのまま再利用できないことがあります。

歴史

[1] HTTP (RFC2068 1.3, RFC2616 1.3)

fresh
A response is fresh if its age has not yet exceeded its freshness lifetime.
新鮮
応答は、その齢が新鮮寿命をまだ超えていなければ、新鮮です。

[5] HTTP (RFC 2068 1.3, RFC 2616 1.3)

freshness lifetime
The length of time between the generation of a response and its expiration time.
新鮮寿命
応答の生成からその満期時刻までの間の時間の長さ。

[35] HTTP (RFC 2068 1.3, RFC 2616 1.3)

heuristic expiration time
An expiration time assigned by a cache when no explicit expiration time is available.
発見的満期時刻
明示満期時刻が利用可能でないときにキャッシュが割り当てた満期時刻。

[16] HTTP (RFC2068 1.3, RFC2616 1.3)

stale
A response is stale if its age has passed its freshness lifetime.
腐敗stale
応答は、その齢が新鮮寿命を過ぎていれば腐っています。

実装

[44] Chrome は、 リダイレクトに Cache-Control: public と Last-Modified: を指定するだけではその応答をキャッシュして再利用しません。 (キャッシュ可能性の条件は満たしているはずで、発見的満期時刻が使われるなら、 再利用されて良さそうですが。) それに更に max-age を指定すると、再利用されるようになります。