
2025/12/24 4:41
**HTTP キャッシュ―リフレッシャー**
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Summary
RFC 9111(2022)は、Cache‑Control ヘッダーをブラウザ、プロキシ、および CDN がキャッシュを制御するために使用するメカニズムとして定義しています。ヘッダーはコンマで区切られたディレクティブの集合です;一部はリクエストにのみ適用され、他はレスポンスにのみ適用されます。
新鮮度と検証
- キャッシュは、レスポンスの age を freshness timeline(
、max-age
/Expires
ヘッダー、またはDate
のヒューリスティック)と比較して新鮮さを判断します。Last‑Modified - 共有キャッシュの場合は
がs-maxage
を上書きします。max-age - キャッシュエントリが古くなっている場合、キャッシュは条件付きリクエストで検証することがあります:
(ETag)またはIf‑None‑Match
。304 レスポンスはキャッシュされた本文を再利用し、200 はそれを書き換えます。If‑Modified‑Since
主要なレスポンスディレクティブ
| ディレクティブ | 効果 |
|---|---|
| max-age | 新鮮さを秒単位で設定します。 |
| must-revalidate | 古いレスポンスは検証しなければならず、失敗すると 504/5xx を返す場合があります。 |
| no-cache | と同等で、全てのキャッシュエントリに対して must‑revalidate が適用されます。 |
| no-store | キャッシュはリクエストまたはレスポンスの任意の部分を永続化してはいけません(揮発性ストレージが推奨されます)。 |
| private / public | 共有キャッシュにレスポンスが保存できるかどうかを制御します( は共有をブロック、 は許可)。 |
| s-maxage | 共有キャッシュ用に を上書きします。 |
| must-understand | キャッシュはディレクティブを理解しなければならないか、リクエストを変更せずに転送しなければなりません。 |
| stale-while-revalidate / stale-if-error | バックグラウンドで再検証が行われる間やエラー時にわずかに古いコンテンツを配信できます。 |
リクエスト側ディレクティブ
同じ名前(例:
max-age, no-cache)はリクエストでも現れ、キャッシュの調整に影響します。only-if-cached ディレクティブは、キャッシュがすでに保存済みのレスポンスを持っている場合のみ返却するよう強制します。
ブラウザのリロード動作
ブラウザは2種類の更新をサポートしています:
- Soft reload – メインリソースを再検証し、サブリソースは通常通り読み込みます。
- Hard reload – すべてのリソースに対して
を送信します。Safari のハードリロード動作は Chrome/Firefox と若干異なります。Cache-Control:no-cache
RFC 8246 – Immutable
immutable ディレクティブは、レスポンスが新鮮期間中に変更されないことを示し、キャッシュはソフトリロード時に条件付きリクエストを発行する必要がありません。
認証済みレスポンス
共有キャッシュは、レスポンスに
public, s-maxage=<n>, または must-revalidate が含まれる場合のみ認証済みレスポンスを保存できます。そうでなければ private がそのようなコンテンツの共有をブロックします。
Cache‑Control を適切に使用するとパフォーマンスが向上し帯域幅が節約されますが、設定ミスは機密データを漏らしたり古いコンテンツを配信したりする原因となります。
本文
RFC 9111 – HTTP キャッシュ(2022)
RFC では
Cache‑Control ヘッダーを、ブラウザキャッシュ・プロキシ・CDN 等の中継キャッシュに対して「レスポンスをどのように保存し再利用するか」を指示する仕組みとして定義しています。
コア概念
| 項目 | 内容 |
|---|---|
| 新鮮度(Freshness) | リクエスト時、キャッシュは格納済みレスポンスがまだ「新鮮」であるか確認します。 • 新鮮 ならそのまま返却可能 • 古い (stale) 場合はオリジンサーバーへ条件付きリクエストで再検証する必要があります |
| Age | レスポンスが生成または最後にオリジンから再検証されてから経過した時間(秒)。中継キャッシュの ヘッダーも加算します。 |
| 新鮮度タイムライン | レスポンスが古くなるまでの期間を決定します。優先順位は以下通りです: 1. (共有キャッシュの場合は )2. と ヘッダー間隔3. に基づくヒューリスティック(明示的な有効期限が無い場合) |
| 検証 (Validation) | 条件付きリクエストに含まれる前提条件: • (優先)• 両方指定されている場合は のみが評価されます。200 OK → 新しいボディ、304 Not Modified → 保存済みレスポンスを再利用 |
Cache‑Control Response ディレクティブ
| ディレクティブ | 意味 |
|---|---|
| max-age=<数値> | レスポンスの新鮮度寿命(秒)を設定します(RFC 9111 §5.2.2.1)。 |
| must‑revalidate | 古いレスポンスは再検証が完了するまで利用できません。エラー時には古い内容ではなく失敗情報を返します。また、共有キャッシュで認証済みレスポンスの保存を許可します。 |
| no‑cache | すべてのレスポンスを使用前に必ず検証させます。 と同等です。 |
| no-store | プライベート・共有キャッシュどちらもリクエストやレスポンスの任意の部分を保存してはなりません。プライバシー保証としては完全ではありません。 |
| must-understand | ステータスコードが不明の場合、キャッシュはそのレスポンスを保存・再利用しないようにします。 と併用されることがあります。 |
| private | 単一ユーザー向けであることを示します。共有キャッシュは格納しませんが、プライベートキャッシュ(ブラウザ等)は格納可能です。認証済みレスポンスの偶発的な共有を防ぎます。 |
| public | 共有キャッシュに対して「通常なら制限される」レスポンスでも保存できるようにします(例:Authorization ヘッダー付き)。 |
| s-maxage=<数値> | と同様ですが、共有キャッシュのみに適用されます。 の意味合いも含みます。 |
| proxy-revalidate | と同等ですが、対象は共有キャッシュのみです。 |
| no-transform | 中継キャッシュがコンテンツを圧縮・最適化等で変更してはなりません。 |
| stale-while-revalidate=<数値> | バックグラウンドで再検証中でも、最大 まで古いレスポンスを返すことができます。 |
| stale-if-error=<数値> | 再検証時にエラーが発生した場合、最大 まで古いレスポンスを返します。 |
Cache‑Control Request ディレクティブ
| ディレクティブ | 意味 |
|---|---|
| max-age=<数値> | クライアントは「指定秒未満の新鮮度」を持つレスポンスを要求します。 |
| max-stale=[<数値>] | 古いレスポンス()を受け入れます。引数なしなら任意に古いものも可。 |
| min-fresh=<数値> | 「残り新鮮度が少なくとも 」のレスポンスを好みます。 |
| no-cache | キャッシュ済みレスポンスは必ず検証してから使用します。 |
| no-store | リクエスト・それに対するレスポンスのどちらもキャッシュしないよう指示します。 |
| no-transform | 中継キャッシュがコンテンツを変換(圧縮等)してはなりません。 |
| only-if-cached | キャッシュ内のレスポンスのみ使用し、無ければ 504 Gateway Timeout を返します。 |
| stale-if-error=<数値> | 再検証が失敗した場合に限り、最大 古いレスポンスを許容します。 |
ブラウザのリフレッシュ機構
| タイプ | 触発方法 | 動作 |
|---|---|---|
| ソフトリロード | Ctrl + R / Cmd + R(または pull‑to‑refresh) | メインリソースを再検証し、サブリソースは通常通りロード。 Firefox: 条件付きリクエスト。 Chrome: 条件付き + 。Safari: メインリソースの不条件リクエスト。 |
| ハードリロード | Ctrl + Shift + R / Cmd + Shift + R(Safari は Cmd + Option + R) | すべてのリソースを として要求し、キャッシュを完全にバイパスします。 |
Immutable レスポンスディレクティブ
RFC 8246(2018)で導入。
immutable は「レスポンスは新鮮度期間中変更されない」ことを示すため、ソフトリロード時にキャッシュが条件付きリクエストを行わずに済みます。
- Firefox はメインリソースのみ再検証しました。
- Chrome & Safari はサブリソースの再検証を自動でスキップするポリシーへ移行し、
のサポートは任意です。immutable
認証付きリクエストと共有キャッシュ
RFC 9111 §3.5
共有キャッシュは
Authorization ヘッダーを含むリクエストに対してレスポンスを保存できるのは、以下のディレクティブがある場合のみです。
publics-maxage=<数値>must-revalidate
private ディレクティブが指定されていると、それ以外の共有キャッシュ許可指示を上書きします。
まとめ
| ディレクティブ | 主な用途 |
|---|---|
, | 公開・共有コンテンツの新鮮度制御 |
, | 動的データで必ず検証させる |
, | 認証済みレスポンスを共有キャッシュに許可/拒否 |
| 長寿命静的資産の不要な再検証を回避 |
, | ネットワーク障害時に見た目速度を向上 |
これらディレクティブを適切に組み合わせることで、ブラウザ・プロキシ・CDN などの中継キャッシュ全体で細やかなキャッシュ挙動を実現しつつ、プライバシーと認証制御も守ることができます。