Cache-Control

Cache-Control は HTTP のヘッダーで、リクエストとレスポンスの両方でキャッシュのためのディレクティブ (指示) が格納されています。リクエストで指定されたディレクティブは、レスポンスでも同じディレクティブを使用しなければならないということではありません。

ヘッダー種別 一般ヘッダー
禁止ヘッダー名 いいえ
CORS セーフリストレスポンスヘッダー はい

構文

キャッシュのディレクティブには、以下のような規則があります。

  • 大文字小文字の区別はありませんが、小文字が推奨されています。
  • 複数のディレクティブはカンマで区切ります。
  • ディレクティブによってはオプションの引数があり、トークンまたは 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>

ディレクティブ

キャッシュ可能性

ブラウザーがレスポンスをキャッシュするのは通常以下の場合です。

  • ステータスコードが 301, 302, 307, 308, 410 の何れかで、かつ
  • Cache-Controlno-store がないか、 もしプロキシの場合は private がなく、 かつ
  • Authorization が設定されていない
  • 以下の何れかに該当する場合
    • ステータスコードが 301, 302, 307, 308, 410 の何れか、または
    • public, max-age s-maxage の何れかが Cache-Control に指定されている、または
    • Expires が設定されている
public
レスポンスが通常はキャッシュ可能でなくても、レスポンスをどのキャッシュにも格納することができます。
private
レスポンスが通常はキャッシュ可能でなくても、ブラウザーのキャッシュにのみ格納することができます。レスポンスがどのキャッシュにも保存されないようにするには、代わりに no-store を使用してください。このディレクティブにはレスポンスがキャッシュに保存されないようにする効果はありません。
no-cache
レスポンスが通常はキャッシュ可能でなくても、レスポンスをどのキャッシュにも格納することができます。しかし、格納されたレスポンスは使用する前に常に元のサーバーとの検証を通さなければならないので、 no-cacheimmutable と組み合わせて使用することはできません。レスポンスがどのキャッシュにも保存されないようにするには、代わりに no-store を使用してください。このディレクティブにはレスポンスがキャッシュに保存されないようにする効果はありません。
no-store
レスポンスをキャッシュに保存することはできません。他のディレクティブを設定することもできますが、最近のブラウザーではレスポンスがキャッシュされることを防ぐために必要なディレクティブはこれだけです。 max-age=0 が暗黙で含まれますmust-revalidate は意味を持ちません。再検証を行うにはレスポンスがキャッシュに格納されている必要がありますが、 no-store はこれを抑止するからです。

有効期限

max-age=<seconds>
リソースが新しいとみなされる最長の時間です。 Expires とは異なり、このディレクティブはリクエスト時刻からの相対時間です。
s-maxage=<seconds>
max-age または Expires ヘッダーを上書きしますが、共有キャッシュ (プロキシなど) だけのためのものです。プライベートキャッシュでは無視されます。
max-stale[=<seconds>]
クライアントが古くなったレスポンスを受け入れることを示します。オプションの値は秒単位で、クライアントが受け入れる古さの上限を示します。
min-fresh=<seconds>
クライアントが、少なくとも指定された秒数の間は新しいままのレスポンスを要求していることを示します。
stale-while-revalidate=<seconds>
クライアントが古いレスポンスを受け入れ、新しいレスポンスをバックグラウンドで非同期にチェックすることを示します。 seconds の値は、クライアントが古いレスポンスを受け入れる時間を示します。詳細については、「Keeping things fresh with stale-while-revalidate」を参照してください。
stale-if-error=<seconds>
新しいレスポンスのチェックに失敗した場合に、クライアントが古いレスポンスを受け入れることを示します。 seconds の値は、当初の有効期限が切れた後に、クライアントが古いレスポンスを受け入れる時間を示します。

再検証と再読み込み

must-revalidate
一度リソースが古くなると、キャッシュは元のサーバーでの検証が成功しない限り、古くなったコピーを使用してはならないことを示します。
proxy-revalidate
must-revalidate と似ていますが、共有キャッシュ (プロキシなど) にのみ適用されます。プライベートキャッシュでは無視されます。
immutable
時間が経ってもレスポンスの本文が変化しないことを示します。リソースは、期限切れでない限り、サーバー上で変化していないため、クライアントは、たとえユーザーが明示的にページを更新した場合でも、更新をチェックするために条件付きの再検証 (If-None-MatchIf-Modified-Since など) を送ってはいけません。この拡張機能を実装していないクライアントは、 HTTP の仕様に従ってこれらの拡張機能を無視しなければなりません。 Firefox では、 immutablehttps:// トランザクションでのみ有効です。詳しくは、こちらのブログ記事を参照してください。

その他

no-transform
中間キャッシュやプロキシが、レスポンスの本文、 Content-Encoding, Content-Range, Content-Type を変更してはいけません。したがって、 Google’s Web Light のようなプロキシやブラウザーの機能を使用して、キャッシュの格納や遅いコネクションにおいてデータを最小化するために画像を変換してはいけません。
only-if-cached
クライアントによって設定され、レスポンスのために「ネットワークを使用しない」ことを示します。キャッシュは、保存されたレスポンスを使用して応答するか、 504 ステータスコードで応答する必要があります。 If-None-Match などの条件付きヘッダーは設定すべきではありません。サーバーがレスポンスの一部として only-if-cached を設定しても効果はありません。

キャッシュの防止

リソースのキャッシュを無効にするには、以下のレスポンスヘッダーを送ることができます。

良い例:
Cache-Control: no-store

 no-store ディレクティブは、新しいリソースがキャッシュされることを防ぎますが、過去のリクエストの結果としてキャッシュ済みの古いリソースが応答するのを防ぐことはできません。 max-age=0 を設定すると、キャッシュが強制的に再検証されます(キャッシュがクリアされます)。

Cache-Control: no-store, max-age=0
悪い例:
Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0

静的な資産のキャッシュ

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

Cache-Control: public, max-age=604800, immutable

再検証の要求

no-cache または max-age=0 を指定すると、クライアントはリソースをキャッシュすることができ、それを使用する前に毎回再検証をしなければならないことを示します。これは、 HTTP リクエストが毎回発生することを意味しますが、コンテンツが有効であれば、 HTTP 本文のダウンロードを飛ばすことができます。

Cache-Control: no-cache
Cache-Control: no-cache, max-age=0

仕様書

仕様書 状態 備考
RFC 8246: HTTP Immutable Responses IETF RFC
RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching IETF RFC
RFC 5861: HTTP Cache-Control Extensions for Stale Content IETF RFC 初回定義

ブラウザーの互換性

BCD tables only load in the browser

関連情報