MS_HTTPCacheControlHeaders

キャッシュ・コントロールのHTTPヘッダ

• TOP > インフラストラクチャ > HTTPヘッダ
  • キャッシュ・コントロールのHTTPヘッダ
  • Cookie
  • セキュリティ強化のHTTPヘッダ

概要

キャッシュ・コントロールの HTTP ヘッダについて。

使い方

キャッシュを制御する

• HTTP/1.1 では、Cache-Control ヘッダを使用する。
• HTTP/1.0 では、Pragma: no-cache ヘッダを使用する。

ディレクティブ	意味
Cache-Control: no-store	どのキャッシュもレスポンスを保存してはイケナイ。
Cache-Control: no-cache	キャッシュをしてもいいが、キャッシュを使用する際、検証を行う。
Cache-Control: public	どのキャッシュでもレスポンスを保存できる。通常はキャッシュできないページ（HTTP 認証、200 OK 以外）をキャッシュする時に指定。
Cache-Control: private	ブラウザのプライベート キャッシュにのみ保存できる。

補足: 名前に反して no-cache は「キャッシュしない」ではない。 「保存はするが、使う前に必ずサーバへ検証をかける」という意味である。 本当に保存させたくないなら no-store を使う。

機密情報を含むページでは、以下のように併記するのが定石である。

Cache-Control: no-store, no-cache, must-revalidate, private
Pragma: no-cache

有効期限を設定する

ディレクティブ	意味
Cache-Control: max-age=XXX	有効期限を設定する（秒）。
Cache-Control: must-revalidate	有効期限切れ後は、必ず再検証してから使用する。

鮮度と検証

検証

サーバーが strong validator または weak validator を提供していれば実行できる。

リロード・ボタン

リロード ボタンを押した場合、再検証が行われる。

must-revalidate

must-revalidate が指定されている場合、
（鮮度切れ後に）再検証が行われる。

検証リクエスト

後述の If-None-Match / If-Modified-Since を使用する。

鮮度

鮮度の寿命をむかえた場合も、検証リクエストが行われる。
鮮度の判定は以下の優先順で行われる。

1. max-age=XXX ヘッダ … 最優先。
2. Expires ヘッダ … 次いで優先される。
   鮮度 = Expires − Date
3. Last-Modified ヘッダ … 次いで優先される（ヒューリスティック）。
   鮮度 ≒ (Date − Last-Modified) / 10

補足: 共有キャッシュ（CDN・リバース プロキシ）では s-maxage が max-age より優先される。 つまり優先順位は s-maxage（共有キャッシュのみ）> max-age > Expires > ヒューリスティック、となる。

ヘッダ

基本的なヘッダ

Cache-Control

キャッシュ機能に関するディレクティブ。

• Request

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached

• Response

Cache-Control: must-revalidate
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: public
Cache-Control: private
Cache-Control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-Control: s-maxage=<seconds>

補足（最新化）: 近年は以下のディレクティブも利用される。

ディレクティブ	意味
immutable	鮮度期間中はリロードでも再検証しない（ハッシュ付き静的ファイル向け）
stale-while-revalidate=<秒>	期限切れ後、裏で再検証しつつ古い応答を返す
stale-if-error=<秒>	オリジンがエラーの場合に古い応答を返す

その他の基本ヘッダ

ヘッダ	意味
Age	プロキシーのキャッシュに入ってからの経過時間（秒）
Expires	レスポンスが陳腐化すると考えられる日時を表す。
Pragma: no-cache	Cache-Control ヘッダが未実装である HTTP/1.0 キャッシュとの後方互換性
Clear-Site-Data	サイトの閲覧データ（クッキー、ストレージ、キャッシュ等）を消去
Warning	起こりうる問題に関する一般警告情報

補足（最新化）: Warning ヘッダは HTTP セマンティクスの改訂（RFC 9111）で廃止された。 新規実装で使用してはならない。

関連するヘッダ

ETag

• 一意な文字列であり、リソースのバージョンを識別する。
• If-Match や If-None-Match で、この値を使用する。

Date

メッセージを生成した日時を表す。

Last-Modified

• リソースが最後に変更された日時を表す。
• If-Unmodified-Since や If-Modified-Since で、この値を使用する。

※ ETag より正確さは低いが、環境によっては計算が容易。

Vary

• 指定したヘッダの内容ごとにキャッシュを分ける必要があることを伝える。
• Vary: User-Agent で、User-Agent 毎に別のキャッシュを作るなどできる。

補足: Vary の指定漏れは、 別ユーザ向けのコンテンツを共有キャッシュが配ってしまうという 深刻な情報漏洩につながる（キャッシュ ポイズニングの一種）。 認証状態で内容が変わる応答には Cache-Control: private を付けるか、 Vary: Authorization, Cookie を明示する。

検証リクエスト (INM / IMS)

If-None-Match (INM)

• strong validator
• 保存されたリソースが指定した ETag のいずれにも一致しない場合に、
  リソース本体が返される（一致すれば 304 Not Modified）。

If-Modified-Since (IMS)

• weak validator
• エンティティが指定した日時より後に変更されている場合に、
  リソース本体が返される（変更がなければ 304 Not Modified）。

補足: 両方を送った場合、サーバは If-None-Match を優先する （RFC 9110）。日時は秒精度しかないため、 1 秒以内の更新を検出できないのが If-Modified-Since の弱点である。

参考

• HTTPヘッダ
• HTTP キャッシュ - MDN
• Cache-Control - MDN
• RFC 9111 - HTTP Caching

---

Tags: IT国際標準, 通信技術, IIS, .NET開発, .NET Core, ASP.NET, ASP.NET MVC