要約

  • 2010年5月のRFC 5861は独立投稿の情報文書で、再検証中に古い応答を出すstale-while-revalidateと、エラー時に古い応答を出すstale-if-errorを別々に定めた。
  • max-age=600, stale-while-revalidate=30の例は新鮮な10分間と追加の30秒を区切る。max-age=600, stale-if-error=1200の例では、年齢900秒の時の発信元500を、Age: 900付きの保存済み200に置き換え得る。
  • 2022年6月のRFC 9111は古い応答を送る明示的な許可の必要性を維持し、旧来のWarningフィールドを廃止した。

更新を待つ間に旧版を届ける

キャッシュは同じ資源を何度も発信元へ取りに行く時間を節約する。保存した応答の新鮮な期間が終われば、通常は再確認が必要になる。変更がなくても通信と処理の往復には時間がかかる。近くにコピーがあるのに、確認が済むまで読者が待つことになる。

RFC 5861は、発信元が短い猶予を与える方法を示した。Cache-Control: max-age=600, stale-while-revalidate=30なら、最初の600秒は新鮮な応答だ。その後の30秒、キャッシュは古くなったコピーを先に送り、裏側で発信元に変更の有無を尋ねられる。読者はすぐにページを見る。次の読者のための確認は続いている。

この猶予には終点がある。訪問者がおらず確認が始まらなかった場合も、確認が終わらなかった場合も、30秒を過ぎた次の要求は通常の処理を待つ。人がまばらに来るページでは、速度の恩恵が少ない。発行者は、新しい編集が届くのを何秒遅らせてもよいかを決めている。キャッシュはその許可を実際の交通量の中で使う。

失敗した発信元を隠す旧版

もう一つのstale-if-errorは、現在の答えを取りに行ったときの障害を扱う。RFCが挙げるのは、500、502、503、504につながる状況である。古いコピーが決められた上限内にあれば、キャッシュは発信元の失敗の代わりに保存していた成功を返せる。

文書の例では、max-age=600, stale-if-error=1200の応答は10分間新鮮だ。総年齢900秒で確認を試み、発信元が500を返す。キャッシュは古い本文を200 OKとして送り、Age: 900を付けられる。成功という状態コードは、今回届けた保存済み表現についてのものだ。Ageを見ると、その表現が発信元で作られ、または再確認されてから時間が経っていると分かる。

追加の1,200秒は新鮮な600秒の後に続く。例では総年齢が1,800秒を超えれば、エラーを通す。短い障害を古い成功でしのぐための枠であり、無期限の成功表示ではない。更新頻度の低い資料なら20分の古さを許せるかもしれない。支払い額や権限の変化を扱う応答では、その古さが別の損害を生む。時間を設定する発行者には、内容ごとの判断が要る。

二つの制御を一つの「古いものを出す」設定に潰すと、条件が見えなくなる。stale-while-revalidateは確認の遅さを隠し、stale-if-errorは実際の失敗を覆う。秒数も引き金も別だ。どちらを許すかは発信元の公開した方針にかかる。

警告フィールドは先に退場した

2010年の文書は、古い応答に0より大きいAgeとWarningが付くことを当時のHTTP規則として想定した。RFC 9111は2022年にWarningを廃止した。ほとんど生成されず、利用者にも表示されていなかったためだ。現在の応答では、Ageやキャッシュ方針を読む方が実際の経過をつかめる。状態コード200だけを見れば、発信元が失敗していた場面は見えない。

2022年の規格は、過去の応答を使う権限の線も引く。no-cacheやmust-revalidateなどの明示的な禁止があれば、キャッシュは古いものを出せない。それ以外も、切断、クライアントや発信元の明示的な許可、外部契約などが必要になる。RFC 5861の二つの拡張は明示的な許可の例として挙げられた。キャッシュが独断で全資源の鮮度を決めるわけではない。

2010年のRFCは独立投稿の情報文書だった。2022年の標準軌道のキャッシュ仕様が、その拡張を許可の具体例として参照した。実際の採用を数えるには、日付のある応答ヘッダー、設定、障害時の記録が必要だ。文書が示す歴史は明確である。発信元が古さの限度を決め、キャッシュが速さと継続性を買い、読者が少し前の世界を見る。