要約

  • HTTPの鮮度は現在の経過時間と鮮度の有効期間の比較で決まり、Ageだけでは判定できない。
  • 再利用の根拠には、時刻、指令、検証結果、期限切れ応答を出す権限、配信表現の指紋が必要である。

運用画面が設定応答の Age: 20 を見て、緑色の「新鮮」表示を出したとする。ところが応答には max-age=10 があり、オリジンへ接続できない間、キャッシュは許可された期限切れ応答として配信している。ヘッダーは正しくても、画面の結論は誤りだ。

RFC 9111は応答の経過時間と鮮度の有効期間を分ける。経過時間が有効期間を超えていなければ新鮮で、超えれば期限切れとなる。判定式は freshness_lifetime > current_age であり、Ageには適用される有効期間も現在の経過時間の全計算も含まれない。

寿命には優先順位がある。共有キャッシュでは s-maxage が優先され、次に max-age、さらに Expires と Date の差が使われる。明示的期限がなければ、条件を満たす応答にヒューリスティックな寿命を与えられるが、規格は単一のアルゴリズムを定めていない。

Age自体も計算値である。オリジンで生成または正常に検証されてからの秒数を推定し、受信したAge、応答遅延、Dateとの差、現在のキャッシュでの滞在時間を組み合わせる。保存応答を検証せず再利用するとき、キャッシュは計算した現在年齢をAgeとして送らなければならない。

したがって20秒は、有効期間60秒なら新鮮、10秒なら期限切れである。期限切れ応答も、切断時または明示的に許可された場合には配信できる。ただし、no-cache や must-revalidate などの適用可能なディレクティブが期限切れ応答の配信を禁じている場合は、再利用できない。プロトコル上許される配信と、価格・権限・設定が業務上有効であることは別問題だ。

必要なのは鮮度判定レシートである。これは証拠を整理するための編集上の提案であり、IETFやRFC 9111が定義するプロトコル要素ではない。キャッシュと設定、要求先、保存応答、配信ダイジェスト、Date、受信・送信Age、要求・応答・滞在時刻、有効期間の根拠、指令、検証結果、期限切れ応答の許可、最終判断を一つに結ぶ。これで再利用理由を再現できる。

出典