diff options
| -rw-r--r-- | files/ja/web/http/headers/cache-control/index.md | 70 |
1 files changed, 35 insertions, 35 deletions
diff --git a/files/ja/web/http/headers/cache-control/index.md b/files/ja/web/http/headers/cache-control/index.md index e5de5698ce..0a4d18f558 100644 --- a/files/ja/web/http/headers/cache-control/index.md +++ b/files/ja/web/http/headers/cache-control/index.md @@ -13,26 +13,26 @@ translation_of: Web/HTTP/Headers/Cache-Control {{HTTPSidebar}} -HTTP ヘッダーフィールドの **`Cache-Control`** には、ブラウザーや共有キャッシュ (Proxy, CDN など) の [キャッシュ](/ja/docs/Web/HTTP/Caching) を制御するためのディレクティブ (指示) が、リクエストとレスポンスの両方に含まれています。 +HTTP ヘッダーフィールドの **`Cache-Control`** には、ブラウザーや共有キャッシュ (Proxy, CDN など) の [キャッシュ](/ja/docs/Web/HTTP/Caching) を制御するためのディレクティブ(指示) が、リクエストとレスポンスの両方に含まれています。 <table class="properties"> <tbody> <tr> - <th scope="row">Header type</th> + <th scope="row">ヘッダー種別</th> <td> - {{Glossary("Request header")}}, - {{Glossary("Response header")}} + {{Glossary("Request header", "リクエストヘッダー")}}, + {{Glossary("Response header", "レスポンスヘッダー")}} </td> </tr> <tr> - <th scope="row">{{Glossary("Forbidden header name")}}</th> - <td>no</td> + <th scope="row">{{Glossary("Forbidden header name", "禁止ヘッダー名")}}</th> + <td>いいえ</td> </tr> <tr> <th scope="row"> - {{Glossary("CORS-safelisted response header")}} + {{Glossary("CORS-safelisted response header", "CORS セーフリストレスポンスヘッダー")}} </th> - <td>yes</td> + <td>はい</td> </tr> </tbody> </table> @@ -79,7 +79,7 @@ HTTP ヘッダーフィールドの **`Cache-Control`** には、ブラウザー - `Shared cache` - : オリジンサーバーとクライアントの間に存在するキャッシュ(Proxy, CDN など)。1 つのレスポンスを保存し、それを複数のユーザーで再利用します。したがって、開発者は共有キャッシュにパーソナライズされたコンテンツをキャッシュとして保存することは避けるべきです。 - `Private cache` - - : クライアント内に存在するキャッシュです。_local cache_ 、あるいは単に _browser cache_ などとも呼ばれます。ユーザーのためにパーソナライズされたコンテンツを保存し、再利用することができます。 + - : クライアント内に存在するキャッシュです。_local cache_ 、あるいは単に _browser cache_ などとも呼ばれます。ユーザーのためにパーソナライズされたコンテンツを保存し、再利用できます。 - `Store response` - : キャッシュ可能な場合には、レスポンスをキャッシュに保存します。しかし、そのまま再利用されるとは限りません。(通常、"キャッシュ" はレスポンスを保存することを意味します。) - `Reuse response` @@ -95,7 +95,7 @@ HTTP ヘッダーフィールドの **`Cache-Control`** には、ブラウザー ## ディレクティブ -このセクションでは、キャッシュに影響を与えるディレクティブ (応答ディレクティブと要求ディレクティブの両方) を列挙します。 +このセクションでは、キャッシュに影響を与えるディレクティブ(応答ディレクティブと要求ディレクティブの両方) を列挙します。 ### レスポンスディレクティブ @@ -109,7 +109,7 @@ Cache-Control: max-age=604800 キャッシュがこのリクエストを保存し、新鮮なうちに後続のリクエストに再利用できることを示す。 -なお、`max-age` はレスポンスを受信してからの経過時間ではなく、オリジンサーバーでレスポンスが生成されてからの経過時間であることに注意してください。したがって、他のキャッシュ (レスポンスが通ったネットワークルート上) が 100 秒間保存した場合（レスポンスヘッダーフィールドの `age` で示される）、ブラウザキャッシュはその鮮度の有効期間から 100 秒を差し引いたものになります。 +なお、`max-age` はレスポンスを受信してからの経過時間ではなく、オリジンサーバーでレスポンスが生成されてからの経過時間であることに注意してください。したがって、他のキャッシュ(レスポンスが通ったネットワークルート上) が 100 秒間保存した場合(レスポンスヘッダーフィールドの `age` で示される)、ブラウザーキャッシュはその鮮度の有効期間から 100 秒を差し引いたものになります。 ``` Cache-Control: max-age=604800 @@ -118,7 +118,7 @@ Age: 100 #### `s-maxage` -レスポンスディレクティブの `s-maxage` も、レスポンスが新鮮である期間を示します (`max-age` に似ています)。しかし、これは共有キャッシュ特有のもので、共有キャッシュは `max-age` が存在する場合は無視します。 +レスポンスディレクティブの `s-maxage` も、レスポンスが新鮮である期間を示します(`max-age` に似ています)。しかし、これは共有キャッシュ特有のもので、共有キャッシュは `max-age` が存在する場合は無視します。 ``` Cache-Control: s-maxage=604800 @@ -146,7 +146,7 @@ Cache-Control: no-cache Cache-Control: max-age=604800, must-revalidate ``` -HTTP では、キャッシュがオリジンサーバーから切り離されたときに、古いレスポンスを再利用することができます。`must-revalidate` はそれを防ぐための方法で、キャッシュは保存されたレスポンスを元のサーバーで再検証するか、それが再利用不可能な場合は 504 (Gateway Timeout) のレスポンスを生成します。 +HTTP では、キャッシュがオリジンサーバーから切り離されたときに、古いレスポンスを再利用できます。`must-revalidate` はそれを防ぐための方法で、キャッシュは保存されたレスポンスを元のサーバーで再検証するか、それが再利用不可能な場合は 504(Gateway Timeout) のレスポンスを生成します。 #### `proxy-revalidate` @@ -162,13 +162,13 @@ Cache-Control: no-store #### `private` -レスポンスディレクティブの `private` は、レスポンスがプライベートキャッシュ(ブラウザのローカルキャッシュなど) にのみ保存されることを示します。 +レスポンスディレクティブの `private` は、レスポンスがプライベートキャッシュ(ブラウザーのローカルキャッシュなど) にのみ保存されることを示します。 ``` Cache-Control: private ``` -ユーザー個人を特定するコンテンツ、特にログイン後に受け取るレスポンスや、クッキーで管理されるセッションについては、`private` ディレクティブを追加する必要があります。 +ユーザー個人を特定するコンテンツ、特にログイン後に受け取るレスポンスや、Cookie で管理されるセッションについては、`private` ディレクティブを追加する必要があります。 パーソナライズされたコンテンツを持つレスポンスに `private` を付け忘れると、そのレスポンスが共有キャッシュに保存され、複数のユーザーによって使用されてしまい、個人情報の漏えいに繋がる可能性があります。 @@ -180,7 +180,7 @@ Cache-Control: private Cache-Control: public ``` -一般に、ページが Basic Auth または Digest Auth の場合、ブラウザは `Authorization` ヘッダーを付けてリクエストを送信します。つまり、レスポンスは制限されたユーザー (アカウントを持つユーザー) のためにアクセス制御され、たとえ `max-age` がついていても基本的に共有キャッシュ可能ではありません。 +一般に、ページが Basic Auth または Digest Auth の場合、ブラウザーは `Authorization` ヘッダーを付けてリクエストを送信します。つまり、レスポンスは制限されたユーザー(アカウントを持つユーザー) のためにアクセス制御され、たとえ `max-age` がついていても基本的に共有キャッシュ可能ではありません。 その制限を解除するために `public` ディレクティブが使用できます。 @@ -210,7 +210,7 @@ Cache-Control: must-understand, no-store 仲介者の中には、さまざまな理由でコンテンツを変換する人がいます。たとえば、転送サイズを小さくするために画像を変換するものがあります。場合によっては、これはコンテンツプロバイダにとって望ましくありません。 -`no-transform` は、仲介者が(キャッシュを実装しているかどうかに関係なく)レスポンスの内容を変換すべきではないことを示します。 +`no-transform` は、仲介者が(キャッシュを実装しているかどうかに関係なく) レスポンスの内容を変換すべきではないことを示します。 注意: [Google’s Web Light](https://support.google.com/webmasters/answer/6211428) は、そのような仲介業者の一種です。これは、キャッシュストアや低速接続のデータを最小化するために画像を変換し、オプトアウトオプションとして `no-transform` をサポートします。 @@ -228,7 +228,7 @@ Cache-Control: public, max-age=604800, immutable <script src=https://example.com/react.0.0.0.js></script> ``` -ユーザーがブラウザをリロードすると、ブラウザはオリジンサーバーに検証のための条件付きリクエストを送信します。しかし、これらの静的リソースは、ユーザーがブラウザをリロードしても決して変更されないため、再検証する必要がありません。 +ユーザーがブラウザーをリロードすると、ブラウザーはオリジンサーバーに検証のための条件付きリクエストを送信します。しかし、これらの静的リソースは、ユーザーがブラウザーをリロードしても決して変更されないため、再検証する必要がありません。 なぜなら、それらは決して変更されないからです。 `immutable` はキャッシュにレスポンスが新鮮な間は不変であることを伝え、サーバーへの不要な条件付きリクエストを回避します。 #### `stale-while-revalidate` @@ -239,21 +239,21 @@ Cache-Control: public, max-age=604800, immutable Cache-Control: max-age=604800, stale-while-revalidate=86400 ``` -上記の例では、レスポンスは 7 日間（604800 s）新鮮です。7 日後、レスポンスは古くなりますが、キャッシュは翌日 (86400 s) のリクエストに再利用することができます。ただし、バックグラウンドでレスポンスを再認識することが条件です。 +上記の例では、レスポンスは 7 日間(604800 s) 新鮮です。7 日後、レスポンスは古くなりますが、キャッシュは翌日(86400 s) のリクエストに再利用できます。ただし、バックグラウンドでレスポンスを再認識することが条件です。 -再バリデーションにより、キャッシュは再び新鮮になるため、クライアントはその期間中は常に新鮮であったかのように見えます。これにより再バリデーションの遅延ペナルティを効果的にクライアントから隠蔽することができます。 +再バリデーションにより、キャッシュは再び新鮮になるため、クライアントはその期間中は常に新鮮であったかのように見えます。これにより再バリデーションの遅延ペナルティを効果的にクライアントから隠蔽できます。 その間にリクエストがなければ、キャッシュは古くなり、次のリクエストは正常に再検証されます。 #### `stale-if-error` -レスポンスディレクティブの `stale-if-error` は、オリジンサーバーがエラー (500、502、503、504) でレスポンスを返したときに、キャッシュが古いレスポンスを再利用できることを指示します。 +レスポンスディレクティブの `stale-if-error` は、オリジンサーバーがエラー(500、502、503、504) でレスポンスを返したときに、キャッシュが古いレスポンスを再利用できることを指示します。 ``` Cache-Control: max-age=604800, stale-if-error=86400 ``` -上記の例では、レスポンスは 7 日間（604800 s）新鮮です。7 日を過ぎると古くなりますが、サーバーがエラーでレスポンスを返した場合はさらに 1 日 (86400 s) 利用することができます。 +上記の例では、レスポンスは 7 日間(604800 s)新鮮です。7 日を過ぎると古くなりますが、サーバーがエラーでレスポンスを返した場合はさらに 1 日(86400 s) 利用できます。 しばらくすると、保存されたレスポンスは正常に古くなりました。つまり、オリジンサーバーがエラーレスポンスを送信した場合、クライアントはそのままエラーレスポンスを受信します。 @@ -269,7 +269,7 @@ Cache-Control: no-cache `no-cache` は、キャッシュに新しいレスポンスがある場合でも、クライアントが最新のレスポンスを要求することを可能にします。 -ブラウザは通常、ユーザーがページを **force reloading** しているときに、リクエストに `no-cache` を追加します。 +ブラウザーは通常、ユーザーがページを **force reloading** しているときに、リクエストに `no-cache` を追加します。 ### `no-store` @@ -279,7 +279,7 @@ Cache-Control: no-cache Cache-Control: no-store ``` -主要なブラウザは `no-store` を使ったリクエストに対応していないことに注意してください。 +主要なブラウザーは `no-store` を使ったリクエストに対応していないことに注意してください。 ### `max-age` @@ -289,15 +289,15 @@ Cache-Control: no-store Cache-Control: max-age=3600 ``` -上記の場合、`Cache-Control: max-age=604800` のレスポンスが 3 時間前にキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用することができません。 +上記の場合、`Cache-Control: max-age=604800` のレスポンスが 3 時間前にキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用できません。 -以下で説明するように、多くのブラウザは **reloading** 時に、このディレクティブを使用します。 +以下で説明するように、多くのブラウザーは **reloading** 時に、このディレクティブを使用します。 ``` Cache-Control: max-age=0 ``` -`max-age=0` は `no-cache` の回避策です。多くの古い (HTTP/1.0) キャッシュの実装は `no-cache` をサポートしていないからです。最近のブラウザは、後方互換性のために `max-age=0` を "reloading" の際に使用し、`no-cache` を使用して "force reloading" を行うようになっています。 +`max-age=0` は `no-cache` の回避策です。多くの古い(HTTP/1.0) キャッシュの実装は `no-cache` をサポートしていないからです。最近のブラウザーは、後方互換性のために `max-age=0` を "reloading" の際に使用し、`no-cache` を使用して "force reloading" を行うようになっています。 ### `max-stale` @@ -307,11 +307,11 @@ Cache-Control: max-age=0 Cache-Control: max-stale=3600 ``` -上記の場合、3 時間前に `Cache-Control: max-age=604800` を持つレスポンスがキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用することができません。 +上記の場合、3 時間前に `Cache-Control: max-age=604800` を持つレスポンスがキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用できません。 クライアントは、オリジンサーバーがダウンしているときや遅すぎるときにこのヘッダーを使うことができ、多少古くてもキャッシュされたレスポンスをキャッシュから受け入れることができます。 -主要なブラウザは `max-stale` を指定したリクエストに対応していないことに注意してください。 +主要なブラウザーは `max-stale` を指定したリクエストに対応していないことに注意してください。 ### `min-fresh` @@ -321,11 +321,11 @@ Cache-Control: max-stale=3600 Cache-Control: min-fresh=600 ``` -上記の場合、51 分前に `Cache-Control: max-age=3600` を持つレスポンスがキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用することができません。 +上記の場合、51 分前に `Cache-Control: max-age=3600` を持つレスポンスがキャッシュに保存されていた場合、キャッシュはそのレスポンスを再利用できません。 クライアントがこのヘッダーを使用できるのは、ユーザーのレスポンスが新鮮であることだけでなく、一定期間更新されないことも要求する場合です。 -主要なブラウザは `min-fresh` を使ったリクエストに対応していないことに注意してください。 +主要なブラウザーは `min-fresh` を使ったリクエストに対応していないことに注意してください。 ### `no-transform` @@ -375,7 +375,7 @@ Cache-Control: no-store React ライブラリのバージョンは、ライブラリを更新すると変わりますし、`hero.png` も画像を編集すると変わります。そのため、これらは `max-age` を使ってキャッシュに保存するのは難しくなります。 -このような場合、特定の番号のついたバージョンのライブラリを使用し、画像の URL にハッシュを含めることでキャッシュの必要性に対応することができます。 +このような場合、特定の番号のついたバージョンのライブラリを使用し、画像の URL にハッシュを含めることでキャッシュの必要性に対応できます。 ```html <!-- index.html --> @@ -383,7 +383,7 @@ React ライブラリのバージョンは、ライブラリを更新すると <img src=/assets/hero.png?hash=deadbeef width=900 height=400> ``` -長い `max-age` 値を追加することができ、コンテンツは決して変更されないので `immutable` とすることができます。 +長い `max-age` 値を追加でき、コンテンツは決して変更されないので `immutable` にできます。 ``` # /assets/* @@ -405,7 +405,7 @@ Cache-Control: no-cache 動的に生成されるコンテンツや、静的であっても頻繁に更新されるコンテンツでは、ユーザーが常に最新版を受信できるようにしたいものです。 -もし、レスポンスがキャッシュされることを意図していないからといって `Cache-Control` ヘッダーを追加しなければ、予期せぬ結果を引き起こす可能性があります。キャッシュストレージは、ヒューリスティックにキャッシュすることが許されています。したがって、キャッシュに関する何らかの要求がある場合は、常に `Cache-Control` ヘッダで明示的に示す必要があります。 +もし、レスポンスがキャッシュされることを意図していないからといって `Cache-Control` ヘッダーを追加しなければ、予期せぬ結果を引き起こす可能性があります。キャッシュストレージは、ヒューリスティックにキャッシュすることが許されています。したがって、キャッシュに関する何らかの要求がある場合は、常に `Cache-Control` ヘッダーで明示的に示す必要があります。 レスポンスに `no-cache` を追加すると、サーバーで再バリデーションが行われるので、毎回新鮮なレスポンスを提供できます。また、クライアントがすでに新しいレスポンスを持っている場合は、`304 Not Modified` とだけレスポンスを返します。 @@ -427,7 +427,7 @@ Cache-Control: max-age=0, must-revalidate クライアント caches が、あるパスに対する新鮮なレスポンスを保存し、サーバーへのリクエストフライトがない状態を想像してください。そのパスに対してサーバーができることは何もありません。 -また、`Clear-Site-Data` はブラウザのキャッシュをクリアすることができます。しかし、これはサイトの保存されたすべてのレスポンスをクリアするので注意してください。そして、ブラウザのみで、共有キャッシュはクリアされません。 +また、`Clear-Site-Data` はブラウザーのキャッシュをクリアできます。しかし、これはサイトの保存されたすべてのレスポンスをクリアするので注意してください。そして、ブラウザーのみで、共有キャッシュはクリアされません。 ## Specifications |