From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- files/ja/web/http/headers/cache-control/index.html | 230 +++++++++++++++++++++ 1 file changed, 230 insertions(+) create mode 100644 files/ja/web/http/headers/cache-control/index.html (limited to 'files/ja/web/http/headers/cache-control') diff --git a/files/ja/web/http/headers/cache-control/index.html b/files/ja/web/http/headers/cache-control/index.html new file mode 100644 index 0000000000..c0de619b14 --- /dev/null +++ b/files/ja/web/http/headers/cache-control/index.html @@ -0,0 +1,230 @@ +--- +title: Cache-Control +slug: Web/HTTP/Headers/Cache-Control +tags: + - Cache-Control + - HTTP + - HTTP ヘッダー + - Reference + - 一般ヘッダー +translation_of: Web/HTTP/Headers/Cache-Control +--- +
{{HTTPSidebar}}
+ +

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

+ + + + + + + + + + + + + + + + +
ヘッダー種別{{Glossary("General header", "一般ヘッダー")}}
{{Glossary("Forbidden header name", "禁止ヘッダー名")}}いいえ
{{Glossary("CORS-safelisted response header", "CORS セーフリストレスポンスヘッダー")}}はい
+ +

構文

+ +

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

+ + + +

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

+ +

クライアントからの 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-store を使用してください。このディレクティブにはレスポンスがキャッシュに保存されないようにする効果はありません。
+
no-cache
+
レスポンスが通常はキャッシュ可能でなくても、レスポンスをどのキャッシュにも格納することができます。しかし、格納されたレスポンスは使用する前に常に元のサーバーとの検証を通さなければならないので、 no-cache を immutable と組み合わせて使用することはできません。レスポンスがどのキャッシュにも保存されないようにするには、代わりに 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> {{Experimental_Inline}}
+
クライアントが古いレスポンスを受け入れ、新しいレスポンスをバックグラウンドで非同期にチェックすることを示します。 seconds の値は、クライアントが古いレスポンスを受け入れる時間を示します。詳細については、「Keeping things fresh with stale-while-revalidate」を参照してください。
+
stale-if-error=<seconds> {{Experimental_Inline}}
+
新しいレスポンスのチェックに失敗した場合に、クライアントが古いレスポンスを受け入れることを示します。 seconds の値は、当初の有効期限が切れた後に、クライアントが古いレスポンスを受け入れる時間を示します。
+
+ +

再検証と再読み込み

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

その他

+ +
+
no-transform
+
中間キャッシュやプロキシが、レスポンスの本文、 {{HTTPHeader("Content-Encoding")}}, {{HTTPHeader("Content-Range")}}, {{HTTPHeader("Content-Type")}} を変更してはいけません。したがって、 Google’s Web Light のようなプロキシやブラウザーの機能を使用して、キャッシュの格納や遅いコネクションにおいてデータを最小化するために画像を変換してはいけません。
+
only-if-cached
+
クライアントによって設定され、レスポンスのために「ネットワークを使用しない」ことを示します。キャッシュは、保存されたレスポンスを使用して応答するか、 {{HTTPStatus("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 ファイルなど、アプリケーションによって提供される静的なファイルが含まれます。加えて、 {{HTTPHeader("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初回定義
+ +

ブラウザーの互換性

+ + + +

{{Compat("http.headers.Cache-Control")}}

+ +

関連情報

+ + -- cgit v1.2.3-54-g00ecf