解説

no-cacheなら保存されない？Cache-Controlのno-storeとの違いを確認しよう

no-cacheは再利用前の検証、no-storeは保存しない指定。応答ヘッダーの例と一時環境の確認を使い、privateや履歴との違いも整理。

この記事の道しるべ 5項目

Cache-Controlにno-cacheと書けば、ブラウザには保存されないのかな。名前からはそう見えるけれど、no-cacheとno-storeは役割が違うよ。

今回はHTTP応答のCache-Controlを対象にする。ブラウザや共有キャッシュが、応答を保存・再利用するときのルールを分けて確認しよう。

no-cacheは、使う前に検証する

HTTP/1.1 200 OK
Cache-Control: no-cache
ETag: "practice-v1"

これは説明用の応答ヘッダーの例。no-cacheは保存を一律に禁止する指定ではなく、保存した応答を再利用する前に、元のサーバーで検証を成功させる必要があることを示す。

ETagなどで同じ内容かを確認し、変更がなければサーバーが304を返す場合がある。本文を毎回すべて送り直すことと、最新かを毎回確かめることは違うね。

HTTP/1.1 200 OK
Cache-Control: no-store

no-storeは、その応答をHTTPキャッシュへ保存しないよう求める指定。個人向けの情報など、保存を避けたい内容を扱うときに関係する。

ただし、これを新たに付ければ、すでに別の場所へ保存された過去のデータまで消えるという意味ではない。履歴、アプリが独自に保存したデータ、キャッシュ以外の仕組みも別に考える必要があるよ。

応答の指定	今回押さえたい意味
no-cache	再利用する前に検証が必要。保存は禁止していない
no-store	HTTPキャッシュへ保存しない
private	共有キャッシュには保存させず、利用者側のキャッシュは許す

privateだけでは、ブラウザの保存を禁止することにはならない。また、これらのヘッダーは認証やアクセス権限そのものの代わりでもないよ。

編集部では、一時的なHTTPサーバーとChromiumで、同じ内容を二回ずつ取得した。no-cache側は最初に200と本文を返し、二回目はIf-None-Matchによる再検証を受けてサーバーが304を返した。

no-store側は二回とも本文付きの200を返し、この例では保存済みETagを使う再検証はなかった。確認したのは、別々のURLに対する通常の取得と、指定したヘッダーの小さな例だけだよ。

ブラウザが保存済みの本文を使ってアプリへ結果を返す場合、アプリから見た応答と、ネットワーク上の304は同じ表示とは限らない。サーバーの記録と開発者ツールなど、どこで見た値かも区別しよう。

以下は設定を検討するときの確認案だよ。

この記事のために本番のキャッシュ設定を変更したわけではないよ。再検証はETagと304、別の保存情報はキャッシュとCookieも参考になるね。

公開と変更の記録

日時は日本時間です。記載のある変更は、確認できた編集記録に基づきます。更新日の違いだけから変更内容を推測して載せることはありません。