Cache-Control

Cache-Control 一般ヘッダーフィールドは、リクエストとレスポンスの両方のキャッシュ規則を指定するために用います。キャッシュの指定は単一方向で、つまり、リクエストの定義がレスポンスの定義と同じにはなりません。

構文

ディレクティブは大文字と小文字の区別をせず、任意の引数を持つことができ、そこには、トークンや quoted-string (複数の単語を""で囲んだ文字列) の書式形式で使用できます。複数指定する場合、コンマで区切ることで指定可能となります。

リクエスト時のキャッシュディレクティブについて

クライアントからの HTTP リクエストで使用される可能性がある、標準的な Cache-Control ディレクティブです。

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

レスポンス時のキャッシュディレクティブについて

サーバーからの HTTP リクエストで使用される可能性がある、標準的な Cache-Control ディレクティブです。

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>

Cache-Control ディレクティブの拡張

Cache-Control ディレクティブの拡張は、主な HTTP のキャッシュ標準ドキュメントには含まれていません。詳しくは、互換性一覧表をご確認ください。

Cache-Control: immutable 
Cache-Control: stale-while-revalidate=<seconds>
Cache-Control: stale-if-error=<seconds>

ディレクティブ

キャッシュ可能性

public

この場合のレスポンスは任意のキャッシュによってキャッシュされます。

private

この場合のレスポンスは単一ユーザー向けであり、共有キャッシュに保存してはいけません。プライベートキャッシュにはレスポンスを保持することができます。

no-cache

キャッシュコピーを破棄する前に、検証のためにキャッシュが元のサーバーへリクエストを送ることを強制します。

only-if-cached

新しいデータを取得しないことを示します。この場合、サーバは、クライアントがレスポンスを1回だけ取得してからキャッシュすることを想定しています。この瞬間から、クライアントはキャッシュされたコピーをリリースしたままにして、起点サーバに連絡して新しいコピーが存在するかどうかを確認する必要があります。

有効期限

max-age=<seconds>

リソースが最新であるとみなされる最大の時間を指定します。 Expiresとは対称的に、このディレクティブはリクエストした時間との相対的な値です。

s-maxage=<seconds>

max-age または Expires ヘッダーよりも優先されますが、 共有キャッシュ (プロキシーやCDNなど) にのみ適用されプライベートキャッシュには適用されません。

max-stale[=<seconds>]

クライアントが有効期限を過ぎたリクエストを受け入れる意思があることを示します。オプションで値を秒単位で割り当てることができます。これはレスポンスが期限切れにならない時間を示します。

min-fresh=<seconds>

クライアントが少なくとも指定された秒数の間も新しいレスポンスを期待していることを示します。

stale-while-revalidate=<seconds>

クライアントが非同期的にバックグラウンドをチェックして新しいものをチェックしている間に、古くなったレスポンスを受け入れる意思があることを示します。seconds の値は、どのくらいまでクライアントが古くなったレスポンスを受け入れるかどうかを示します。

stale-if-error=<seconds>

新しいものの検査が失敗した場合、クライアントが古くなったレスポンスを受け入れる意思があることを示します。秒の値は、クライアントが最初の期限切れ後に古くなったレスポンスを受け入れることができる期間を示します。

再検証と再読み込み

must-revalidate

有効期限切れリソースのキャッシュを利用する前に必ず再検証を行う必要があります、また有効期限切れのリソースには使用しないでください。

proxy-revalidate

must-revalidate と同じですが、共有キャッシュ（プロキシーやCDNなど）にのみ適用されプライベートキャッシュには適用されません。

immutable

レスポンス内容が時間と共に変化しないことを示します。リソースが有効期限切れであってもサーバー上で変更される事はないので、ユーザーが明示的にページを更新した場合でも、クライアントは更新を確認するための条件付きの再検証（If-None-Match や If-Modified-Since）を送信してはいけません。 この拡張機能を認識していないクライアントは、HTTPの仕様に従って無視する必要があります。Firefoxでは、immutableは https:// トランザクションの場合のみ有効です。 詳細に関してはこのブログも参照してください。

その他

no-store

クライアントのリクエストやサーバーのレスポンスに関して、何もキャッシュするべきではありません。

no-transform

リソースへの変更や変換は行わないでください。Content-Encoding、Content-Range、Content-Type ヘッダーは、プロキシによって変更してはいけません。非透過プロキシは、例えば、キャッシュスペースを節約したり、低速リンク上のトラフィック量を減らすために、画像フォーマット間で変換することができます。no-transform ディレクティブはこれを許可しません。

例

キャッシュの防止

キャッシュをしないようにしたい場合は、以下のレスポンスヘッダーを送ることができます。加えて、 Expires 及び Pragma ヘッダーも参照してください。

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

静的なリソースのキャッシュ

アプリケーション内で変更がないようなファイルについては、一般的に以下のようなレスポンスヘッダーを送信して積極的にキャッシュを追加できます。 これには例えば、アプリケーションによって提供される画像、CSS、JavaScript などの静的なファイルが含まれます。加えて、 Expires ヘッダーも参照してください。

Cache-Control: public, max-age=31536000

仕様書

ブラウザーの対応

このページの互換性一覧表は構造化データから生成されています。データに協力したいのであれば https://github.com/mdn/browser-compat-data をチェックアウトしてプルリクエストを送信してください。

関連情報

• HTTP キャッシュ FAQ
• Age
• Expires
• Pragma