public他の条件も満たす場合に共有保存を許可します。
1行16列
HTTP & Request Debugging
Cache-Controlヘッダージェネレーター二つのキャッシュの寿命を確認
応答ヘッダーを解析するか、フォームで指示子を組み合わせます。経過秒数は算例用の仮定です。
Cache-Controlヘッダージェネレーター
入力はこのブラウザー内で処理され、オリジンへの要求は送りません。
ブラウザー／私有キャッシュ
この年齢の算例では新鮮
max-age：寿命3600秒
新鮮期の残り：3600秒
共有キャッシュ／CDN
この年齢の算例では新鮮
s-maxage：寿命86400秒
新鮮期の残り：86400秒
これらの指示子では、古くなった後の再利用前に検証が必要です。
保存済み応答と下で指定する年齢を仮定します。新鮮であっても保存や再利用の保証にはならず、他のヘッダーや配信設定も影響します。
current_ageを0から2147483648で仮定します。Ageだけでは転送・滞留時間の全てを含められません。実測ではなく静的な算例です。
解析した指示子
max-age=3600私有側、およびs-maxageのない共有側の新鮮期です。
1行24列
s-maxage=86400共有側のmax-ageを上書きします。ブラウザーには適用しません。
1行38列
3件中3件を表示
ポリシーの注意点
対象の指示子に問題は見つかりませんでした。配信設定の検証ではありません。
指示子3件・注意点0件
更新したページがブラウザーでは古く、共有キャッシュではまだ新鮮という状況は、二つの寿命を分けると理解しやすくなります。Cache-Controlヘッダージェネレーターでは同じ応答を二つの視点で確認できます。
Cache-Controlヘッダー生成と既存値の解析を別の入力として扱います。HTTPキャッシュの設定を調べながら、未知の拡張やフィールド名を含む引数をフォームへの変換で失うことがありません。
Cache-Controlヘッダージェネレーターを使う理由
解析の手掛かりを残す
Cache-Controlヘッダージェネレーターは重複した指定も順序も残します。private="X-Foo, X-Bar"のカンマは引数の一部として扱います。フォームで新しい値を作っても、調査中の元の入力は上書きしません。
同じ年齢で寿命を比較する
初期例ではmax-ageが3600秒、s-maxageが86400秒です。仮定する現在の年齢を4000秒にすると、ブラウザー側は古くなり、共有側には82400秒残ります。これはキャッシュ有効期間の算例であり、実際のヒット判定ではありません。
値を変える前に確認したい三つの点
01
ヘッダーの範囲を絞る
値だけを一行で入力するか、Cache-Control:付きの行を複数入力できます。AgeやETagを混ぜた応答全体は受け付けません。一部分だけを無言で読み飛ばすことを防ぎます。
02
空欄とゼロを使い分ける
フォームの時間欄は空欄なら省略し、0ならゼロ秒を出力します。例の読み込みと消去は置換内容を確認してから適用します。取り消しで両モードの入力と前の結果を一度復元できます。
03
算例の更新を確かめる
自動解析は編集停止から350ミリ秒後です。オフにすると実行ボタンかCtrl/Cmd + Enterを使えます。編集直後は以前の結果をコピーできません。年齢は実測値でも自動で進む時計でもありません。
指示子の指定と効果を読み解く
引数を保った解析
指示子名は大文字小文字を区別せず、出力では小文字にします。引数の表記、引用符、順序、重複は保持し、空のカンマ要素は省略します。各指示子の行と列も表示します。
応答用のフォーム
九つのスイッチと四つの時間欄から値を構成します。max-age、s-maxageに加え、stale-while-revalidateとstale-if-errorも指定できます。秒数は0から2147483648までの整数です。
保存と再利用を分ける
通常のno-cacheは再利用前の検証を要求し、no-storeは保存を禁止します。正の寿命があるだけで保存可能とは断定できません。共有キャッシュではs-maxageがmax-ageより優先されます。
判断できない理由を示す
未知の拡張、フィールド限定、must-understandは追加の文脈が必要です。既知の指示子の重複や不正な引数がある場合は数値の結論を控えます。表示は50件ずつでも、コピーとテキスト保存はヘッダー全体を含みます。
この解析で分かる範囲
- 応答の単一フィールドが対象
- URL取得やリクエスト送信は行わず、ETag、Vary、Expiresの組み合わせも評価しません。要求専用の指示子は残して対象外と説明します。サーバー設定断片や一括ファイル入力も扱いません。
- 実際の失効時刻は計算しない
- 現在の年齢は利用者が仮定した秒数です。Date補正、転送遅延、滞留時間は算出しません。明示的な寿命がない場合でも、別のExpiresやヒューリスティックな鮮度が存在する可能性があります。
- 配信基盤の判定を代行しない
- CDNの上書き設定、認証、状態コード、キャッシュキーで結果は変わります。警告がないことは運用上の合格を意味しません。キャッシュ消去やヒット保証もありません。
- 上限を超える入力は止める
- 入力は16384個のUTF-16単位、128指示子までです。構文エラーでは出力操作を止めて位置を示します。範囲外の解析秒数は原文のまま残し、数値を推測しません。生成値と仮定の年齢の上限は2147483648です。
- 古い応答の許容は別の条件
- stale-while-revalidateとstale-if-errorは新鮮な期間に加算しません。期限後の再利用には実装やエラー等の条件があります。検証制約との併記は注意点として示し、配信結果までは模擬しません。
Cache-Controlヘッダージェネレーターの質問
no-cacheとno-storeでは何が違いますか？
通常のno-cacheは保存を許しつつ、次の再利用前に成功した検証を必要とします。通常のno-storeは応答の保存を禁止します。どちらも既にあるすべてのコピーを消す操作ではありません。
immutableを付けると再検証はどうなりますか？
immutableは新鮮な間に内容が変わらないことを示し、通常の再検証を省けるようにします。強制再読み込みを常に防ぐわけではなく、古くなった後は通常の扱いに戻ります。引数は無視され、複数回指定しても一回と同じです。
max-ageとs-maxageはそれぞれどこに適用されますか？
max-ageは私有キャッシュ、およびs-maxageのない共有キャッシュに適用されます。s-maxageは共有側の寿命を指定し、古い応答の再利用には検証を求めます。ブラウザー側の期間は延長しません。
publicとprivateはどう使い分けますか？
複数利用者で共有できる応答にはpublicが候補になります。個人向けの応答にはprivate等の制限を検討しますが、認証や内容も確認が必要です。privateは暗号化ではなく、フィールド名付きの形式は全体への制限と異なります。
stale-while-revalidateを指定するとどうなりますか？
新鮮さが失われた後、指定された期間内でバックグラウンド検証を試みながら古い応答を返せる拡張です。要求が来ることや実装の対応も必要で、常に古い応答が返る保証はありません。このツールは新鮮期とは分けて説明します。
問題がありますか？