HTTPキャッシュ：使う、確かめる、取り直す

max-age、ETag、304、no-cache、no-store。保存と再利用を分けて考えると、似た名前の設定がつながる。

本文と一緒に、再利用の条件を受け取る

記事へのGETに対し、サーバーが 200 OK、本文v1、Cache-Control: max-age=60、ETag: "v1" を返したとします。ここではブラウザの個人用キャッシュを扱います。

max-age は応答の鮮度を判断する条件、ETagは表現の版を見分ける検証子です。ETagの値が必ず連番やファイルのハッシュになるわけではありません。

図では保存直後のageを0とし、転送時間などを省いています。実際のage計算にはDateやAgeなども関わります。RFC 9111：鮮度

20秒後、同じ条件のGETが必要になりました。age 20秒はmax-age 60秒より小さいので、保存済み応答はfreshです。この例ではキャッシュから本文を返せます。

ここで重要なのは、保存できることと、今そのまま使えることは別だという点です。応答やリクエストの指示、キャッシュキーの一致など、再利用の条件が満たされている必要があります。

Vary が指定されていれば、そのヘッダーに応じて別の表現を区別します。CDNなどの共有キャッシュや利用者ごとの情報には、さらにprivateや認証に関する条件があります。

今度は70秒後です。保存済み応答はstaleになりました。この作品では、staleな応答をそのまま使う許可はないものとし、再検証へ進みます。

ブラウザは If-None-Match: "v1" を付けた条件付きGETを送ります。「今の版がv1と同じなら、本文をもう一度送らなくてよい」という問い合わせです。

期限切れは、保存した本文が必ず間違っているという意味でも、直ちに削除すべきという意味でもありません。そのまま使うには鮮度が足りないので、サーバーに確かめます。RFC 9111：検証

現在の版もv1なら、サーバーは 304 Not Modified を返せます。304の応答には、このGETで使う表現の本文は含まれません。

ブラウザは適切な保存済み応答を見つけ、304のヘッダーで情報を更新し、その本文を利用します。本文の再転送は省けても、サーバーとの往復は発生しています。 freshなキャッシュだけで済む場面とはここが違います。

304だけを保存済み本文なしで受け取っても、本文が生まれるわけではありません。条件付きリクエストとキャッシュが対になる仕組みです。RFC 9111：304の取り扱い

サーバー上の記事がv2に変わっていれば、v1という条件は一致しません。通常のGETの応答として 200 OK、新しい本文、ETag: "v2" が返ります。

ブラウザは応答の指示に従って、保存済み情報を更新します。再検証は「304をもらう手順」と決めつけると誤ります。変化がないと確認できれば304、変化があれば本文も受け取るという分岐です。

ETagは新鮮さの秒数を表していません。max-ageが「いつ確かめるか」、ETagが「どう版を確かめるか」に関わる、と役割を分けて覚えます。

引数なしの Cache-Control: no-cache は、保存済み応答を再利用する前に、オリジンで正常に検証することを求めます。保存そのものはできます。同じ版なら304を使う余地があります。

Cache-Control: no-store は、そのリクエストやレスポンスに関する保存を禁じる指示です。過去に別の条件で保存した全コピーを消去する命令でも、機密情報をあらゆる場所から消せる保証でもありません。

この作品ではフィールド名付きno-cacheなどの細かい形式は扱いません。RFC 9111：no-cache、no-store

答えはいいえです。保存済みの版を条件付きGETで検証し、304なら手元の本文を利用できます。

図の三つの箱を、通信量と往復の違いとして読みます。freshなら通信なしで使える場合があります。期限切れで同じ版なら、往復しても本文の転送は省けます。変更されていれば、本文も受け取ります。

キャッシュ設定を見るときは「保存を許すか」「そのまま使える期間はいつまでか」「再検証に何を使うか」を分けて確認すると、挙動を予測しやすくなります。