Cache-Control ヘッダービルダー
RFC 9111 に従う有効な Cache-Control ヘッダーを組み立てる。必要なディレクティブ(no-cache、no-store、immutable …)にチェックを入れ、鮮度ウィンドウ(max-age、s-maxage、stale-while-revalidate、stale-if-error)を設定し、結果のヘッダーをコピーする。最も一般的なデプロイパターンをカバーする 4 つのプリセットを含む:不変な静的アセット、プライベートにレンダリングされたページ、stale 提供を伴うパブリック API レスポンス、完全な no-store。
—
プリセット
可視性
鮮度(秒)
ディレクティブ
出力
Cache-Control: public, max-age=3600no-store は他のすべてのディレクティブを上書き — オンの場合、no-transform のみが追加で出力される。
使い方
- あなたのシナリオに合うプリセットから始めて調整。
- 数値フィールドは秒 — 空欄にするとそのディレクティブを完全に省略。
- 結果をオリジンサーバー、CDN ルール、またはフレームワークのレスポンスヘッダーにコピー。
よくある質問
- immutable はいつ使う?
- ファイル名にコンテンツハッシュを含むアセットに、長い max-age(1 年がよくある)と組み合わせて使う。すると、ブラウザは通常ソフトリフレッシュ時に行う条件付き再検証をスキップする。
- no-cache vs no-store?
- no-cache は使用前に保存されたコピーを再検証する必要があることを意味し、no-store はまったく保存しないことを意味する。レスポンスにディスクに置いてはならないプライベートデータが含まれる場合は no-store が勝つ。
- ヘッダーを設定したのにキャッシュされません。なぜ?
- たいていは三つのどれかです。Set-Cookieを一緒に返す応答は共有キャッシュに個人向けと見なされ、CDNはふつう素通りさせます。資格情報付きの要求は、明示的に許可しないかぎり共有キャッシュに保存されません。そしてブラウザーの再読み込みはヘッダーに関係なく再検証するので、強制再読み込みで試すとつねにヘッダーが無視されているように見えます。新しいタブでURLを開いて確かめてください。
- ExpiresやETagとはどう噛み合いますか?
- 両方ある場合はmax-ageがExpiresに勝ちます。ExpiresはCache-Controlを解さない古いキャッシュにしか意味がありません。ETagとLast-Modifiedはまったく別の仕組みで、鮮度には関わらず、応答が古くなったあとの要求を安くします。サーバーは本文なしの304で答えられるようになります。二つは併用するためのものです。
関連ツール
HTTP ヘッダリファレンス
標準 HTTP リクエスト・レスポンス・CORS・キャッシュ・セキュリティ・Cookie ヘッダ 約50個の検索可能リファレンス。
開発 0 0
HTTP Basic 認証エンコーダ / デコーダ
`username:password` を Base64 `Authorization: Basic` ヘッダーにエンコード — または既存のヘッダーを貼り付けて誰がそこにいるかを見る。
ネットワーク 0 0
HTTP ステータスコード リファレンス
1xx-5xx の全 HTTP ステータスコードを検索 — 概要・RFC・使い時・よくある落とし穴付き。
ネットワーク 0 0
HTTP Cookie パーサー
`Cookie:` リクエストヘッダや `Set-Cookie:` レスポンスヘッダを貼り付けて、各クッキーの名前、値、属性、警告を表示。
開発 0 0
日付フォーマット変換
ISO・RFC・Unix epoch・ロケールなど任意の日付を入力すると、14 種類以上の標準フォーマットで並列表示。
時間 0 0
CORS ヘッダービルダー
チェックリストから Access-Control-* レスポンスヘッダーを構成、4 つのプリセットと危険な組み合わせのライブ警告付き。
ネットワーク 0 0