diff options
| -rw-r--r-- | files/ja/web/http/headers/cache-control/index.md | 48 |
1 files changed, 24 insertions, 24 deletions
diff --git a/files/ja/web/http/headers/cache-control/index.md b/files/ja/web/http/headers/cache-control/index.md index 0a4d18f558..c6250d1858 100644 --- a/files/ja/web/http/headers/cache-control/index.md +++ b/files/ja/web/http/headers/cache-control/index.md @@ -91,11 +91,11 @@ HTTP ヘッダーフィールドの **`Cache-Control`** には、ブラウザー - `Stale response` - : レスポンスが古い状態になっていることを示します。これは通常、レスポンスがそのままでは再利用できないことを意味します。キャッシュストレージは古いレスポンスをすぐに削除する必要はありません。なぜなら、再検証によってレスポンスが古いものから再び新しい状態に変わる可能性があるからです。 - `Age` - - : レスポンスが生成されてからの時間です。レスポンスが新しい状態か古い状態かの基準となります。 + - : レスポンスが生成されてからの経過時間です。レスポンスが新しい状態か古い状態かの基準となります。 ## ディレクティブ -このセクションでは、キャッシュに影響を与えるディレクティブ(応答ディレクティブと要求ディレクティブの両方) を列挙します。 +このセクションでは、キャッシュに影響を与えるディレクティブ(レスポンスディレクティブとリクエストディレクティブの両方) を列挙します。 ### レスポンスディレクティブ @@ -107,9 +107,9 @@ HTTP ヘッダーフィールドの **`Cache-Control`** には、ブラウザー 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` に似ています)。しかし、これは共有キャッシュ特有のもので、共有キャッシュは `s-maxage` と `max-age` の両方が存在した場合 `max-age` を無視します。 ``` Cache-Control: s-maxage=604800 @@ -132,9 +132,9 @@ Cache-Control: s-maxage=604800 Cache-Control: no-cache ``` -キャッシュに常にコンテンツの更新をチェックさせる一方で、保存されているコンテンツに変更がない場合再利用させたい場合は、`no-cache` を使用する必要があります。これは、キャッシュがオリジンサーバーに各リクエストを再確認することを要求することで実現されます。 +キャッシュに、保存されているコンテンツを再利用する際に、必ず更新がないかどうかをチェックさせたい場合は、 `no-cache` を使用する必要があります。これは、キャッシュがオリジンサーバーに各リクエストを再確認することを要求することで実現されます。 -`no-cache` はキャッシュにレスポンスを保存することを許可しますが、再利用する前に再確認することを要求します。もし、「キャッシュしない」の意味が実際には「保存しない」であるなら、`no-store` が使用すべきディレクティブです。 +`no-cache` はキャッシュにレスポンスを保存することを許可しますが、再利用する前に再確認することを要求します。もし、「キャッシュさせない」の意味が実際には「保存させない」であるなら、`no-store` が使用すべきディレクティブです。 #### `must-revalidate` @@ -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,7 +162,7 @@ Cache-Control: no-store #### `private` -レスポンスディレクティブの `private` は、レスポンスがプライベートキャッシュ(ブラウザーのローカルキャッシュなど) にのみ保存されることを示します。 +レスポンスディレクティブの `private` は、レスポンスがプライベートキャッシュ(ブラウザーのローカルキャッシュなど) にのみ保存できることを示します。 ``` Cache-Control: private @@ -170,7 +170,7 @@ Cache-Control: private ユーザー個人を特定するコンテンツ、特にログイン後に受け取るレスポンスや、Cookie で管理されるセッションについては、`private` ディレクティブを追加する必要があります。 -パーソナライズされたコンテンツを持つレスポンスに `private` を付け忘れると、そのレスポンスが共有キャッシュに保存され、複数のユーザーによって使用されてしまい、個人情報の漏えいに繋がる可能性があります。 +パーソナライズされたコンテンツを持つレスポンスに `private` を付け忘れると、そのレスポンスが共有キャッシュに保存され、複数のユーザーによって再利用されてしまい、個人情報の漏えいに繋がる可能性があります。 #### `public` @@ -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` ディレクティブが使用できます。 @@ -208,11 +208,11 @@ Cache-Control: must-understand, no-store #### `no-transform` -仲介者の中には、さまざまな理由でコンテンツを変換する人がいます。たとえば、転送サイズを小さくするために画像を変換するものがあります。場合によっては、これはコンテンツプロバイダにとって望ましくありません。 +Intermedialies(仲介者) の中には、さまざまな理由でコンテンツを変換する人がいます。たとえば、転送サイズを小さくするために画像を変換するものなどです。場合によっては、これはコンテンツプロバイダにとって望ましくありません。 `no-transform` は、仲介者が(キャッシュを実装しているかどうかに関係なく) レスポンスの内容を変換すべきではないことを示します。 -注意: [Google’s Web Light](https://support.google.com/webmasters/answer/6211428) は、そのような仲介業者の一種です。これは、キャッシュストアや低速接続のデータを最小化するために画像を変換し、オプトアウトオプションとして `no-transform` をサポートします。 +注意: [Google’s Web Light](https://support.google.com/webmasters/answer/6211428) は、そのような仲介者の一種です。これは、キャッシュストアや低速接続のデータを最小化するために画像を変換し、オプトアウトオプションとして `no-transform` をサポートします。 #### `immutable` @@ -239,9 +239,9 @@ 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) のリクエストに再利用できます。ただし、バックグラウンドでレスポンスを再検証することが条件です。 -再バリデーションにより、キャッシュは再び新鮮になるため、クライアントはその期間中は常に新鮮であったかのように見えます。これにより再バリデーションの遅延ペナルティを効果的にクライアントから隠蔽できます。 +再検証により、キャッシュは再び新鮮になるため、クライアントはその期間中は常に新鮮であったかのように見えます。これにより再検証の遅延ペナルティを効果的にクライアントから隠蔽できます。 その間にリクエストがなければ、キャッシュは古くなり、次のリクエストは正常に再検証されます。 @@ -255,7 +255,7 @@ Cache-Control: max-age=604800, stale-if-error=86400 上記の例では、レスポンスは 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` @@ -283,7 +283,7 @@ Cache-Control: no-store ### `max-age` -リクエストディレクティブの `max-age=N` は、オリジンサーバーで _N_ 秒以内に生成される保存されたレスポンスをクライアントが許可することを示します。 +リクエストディレクティブの `max-age=N` は、オリジンサーバーで _N_ 秒以内に生成された、保存済みレスポンスをクライアントが許可することを示します。 ``` Cache-Control: max-age=3600 @@ -333,7 +333,7 @@ Cache-Control: min-fresh=600 ### `only-if-cached` -クライアントは、キャッシュがすでにキャッシュされたレスポンスを取得する必要があることを示します。キャッシュにレスポンスが保存されている場合は、再利用されます。 +クライアントは、キャッシュがすでに保存済みのレスポンスを転送する必要があることを示します。キャッシュにレスポンスが保存されている場合、それが再利用されます。 ## Use Cases @@ -363,7 +363,7 @@ Cache-Control: no-store ### Caching static assets with “cache busting” -バージョン/ハッシュ機構を持つ静的資産を構築する場合、ファイル名やクエリ文字列にバージョン/ハッシュを追加することは、キャッシュを管理するための良い方法です。 +バージョン/ハッシュビルドを持つ静的アセットを構築する場合、ファイル名やクエリ文字列にバージョン/ハッシュを追加することは、キャッシュを管理するための良い方法です。 例： @@ -375,7 +375,7 @@ Cache-Control: no-store React ライブラリのバージョンは、ライブラリを更新すると変わりますし、`hero.png` も画像を編集すると変わります。そのため、これらは `max-age` を使ってキャッシュに保存するのは難しくなります。 -このような場合、特定の番号のついたバージョンのライブラリを使用し、画像の URL にハッシュを含めることでキャッシュの必要性に対応できます。 +このような場合、特定の番号のついたバージョンのライブラリを使用し、画像の URL にハッシュを含めることでキャッシュの要求を満たすことができます。 ```html <!-- index.html --> @@ -399,7 +399,7 @@ Cache-Control: max-age=31536000, immutable Cache-Control: no-cache ``` -注意: `index.html` が基本認証またはダイジェスト認証で制御されている場合、`/assets` 以下のファイルは共有キャッシュに保存されません。もし `/assets/` のファイルが共有キャッシュに保存するのに適しているなら、 `public`、`s-maxage` または `must-revalidate` のうちの 1 つが必要です。 +注意: `index.html` がベーシック認証またはダイジェスト認証で制御されている場合、`/assets` 以下のファイルは共有キャッシュに保存されません。もし `/assets/` のファイルが共有キャッシュに保存するのに適しているなら、 `public`、`s-maxage` または `must-revalidate` のうちの 1 つが必要です。 ### Up-to-date contents always @@ -425,9 +425,9 @@ Cache-Control: max-age=0, must-revalidate 残念ながら、すでに保存されているレスポンスをキャッシュからクリアするためのキャッシュディレクティブはありません。 -クライアント caches が、あるパスに対する新鮮なレスポンスを保存し、サーバーへのリクエストフライトがない状態を想像してください。そのパスに対してサーバーができることは何もありません。 +クライアントやキャッシュが、あるパスに対する新鮮なレスポンスを保存しており、サーバーへリクエストを送信しない状態を想像してください。そのパスに対してサーバーができることは何もありません。 -また、`Clear-Site-Data` はブラウザーのキャッシュをクリアできます。しかし、これはサイトの保存されたすべてのレスポンスをクリアするので注意してください。そして、ブラウザーのみで、共有キャッシュはクリアされません。 +代替として `Clear-Site-Data` はブラウザーのキャッシュをクリアできます。しかし、これはサイトの保存されたすべてのレスポンスをクリアするので注意してください。そして、ブラウザーのみで、共有キャッシュはクリアされません。 ## Specifications |