明示的満期時刻

新鮮 (HTTP)

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

仕様書

満期時刻

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

[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警告符号 113Warning: ヘッダーを (既に無ければ >>19) 生成するべきです >>40, >>19

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

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

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

110, 111 も参照。

[30] キャッシュは、キャッシュが“切断されている”場合の腐敗応答警告符号 112Warning: ヘッダー生成するべきです >>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: publicLast-Modified: を指定するだけではその応答キャッシュして再利用しません。 (キャッシュ可能性の条件は満たしているはずで、発見的満期時刻が使われるなら、 再利用されて良さそうですが。) それに更に max-age を指定すると、再利用されるようになります。