2. Cache-Status HTTPレスポンスヘッダーフィールド
Cache-Status HTTPレスポンスヘッダーフィールドは、キャッシュがそのレスポンスと対応するリクエストをどのように処理したかを示します。このヘッダーフィールドの構文は[STRUCTURED-FIELDS]に準拠しています。
その値はListです。Listの各メンバーは、リクエストを処理したキャッシュを表します。最初のメンバーはオリジンサーバーに最も近いキャッシュを表し、最後のメンバーはユーザーに最も近いキャッシュを表します（値を追加する場合、ユーザーエージェントのキャッシュ自体を含む可能性があります）。
キャッシュは、レスポンスにCache-Statusヘッダーフィールドを追加するのが適切な時期を決定します。一部はすべてのレスポンスに追加する可能性がありますが、他の一部は特別に設定された場合、またはリクエストにデバッグモードをアクティブにするヘッダーフィールドが含まれている場合にのみ追加します。関連するセキュリティの考慮事項については、セクション6を参照してください。
中間装置は、ローカルで生成するレスポンスにCache-Statusメンバーを追加すべきではありません（SHOULD NOT）。その中間装置にキャッシュが含まれている場合でも、生成されたレスポンスが保存されたレスポンスに基づいている場合を除きます（例えば、304（Not Modified）と206（Partial Content）はどちらも保存されたレスポンスに基づいています）。例えば、不正なリクエストのために400レスポンスを生成するプロキシは、Cache-Status値を追加しません。なぜなら、そのレスポンスはプロキシによって生成されたものであり、オリジンサーバーによって生成されたものではないからです。
Cache-Statusヘッダーフィールドに値を追加する場合、キャッシュは既存のフィールド値を保持すべきです（SHOULD）。これにより、リクエストを処理するキャッシュチェーン全体のデバッグが可能になります。
Listの各メンバーは、それを挿入したキャッシュを識別し、この識別子はStringまたはTokenでなければなりません（MUST）。デプロイメントに応じて、これは製品またはサービス名（例：「ExampleCache」または「Example CDN」）、ホスト名（「cache-3.example.com」）、IPアドレス、または生成された文字列である可能性があります。
リストの各メンバーは、そのキャッシュによるリクエストの処理を記述するパラメータを持つことができます。これらのパラメータはオプション（OPTIONAL）ですが、キャッシュはできるだけ多くの情報を提供することが推奨されます。
この仕様は以下のパラメータを定義します。
2.1. hit パラメータ
「hit」の値はBooleanであり、trueの場合、リクエストがキャッシュによって満たされたことを示します。つまり、転送されず、レスポンスはキャッシュから取得されました。
オリジンによって元々生成されたがキャッシュによって変更されたレスポンス（例えば、304または206ステータスコード）は、転送されなかった限り（例えば、検証のため）、依然としてhitと見なされます。
キャッシュ内にあったが転送なしでは使用できなかったレスポンス（例えば、古くなっているか部分的であるため）は、hitとは見なされません。オリジンサーバーが利用できないために転送なしで使用される古いレスポンスは、hitと見なすことができることに注意してください。
「hit」と「fwd」は相互に排他的です。各リストメンバーには、どちらか一方のみが表示されるべきです。
2.2. fwd パラメータ
「fwd」が存在する場合、リクエストがオリジンに向かって転送されたことを示します。その値は理由を示すTokenです。
リクエストが転送された理由を説明するために、最も具体的なものから最も一般的なものまで、次のパラメータ値が定義されています：
bypass：キャッシュはこのリクエストを処理しないように設定されていました。
method：リクエストメソッドのセマンティクスにより、リクエストを転送する必要があります。
uri-miss：キャッシュには、リクエストURIに一致するレスポンスが含まれていませんでした。
vary-miss：キャッシュには、リクエストURIに一致するレスポンスが含まれていましたが、このリクエストのヘッダーフィールドと保存されたVaryヘッダーフィールドに基づいてレスポンスを選択できませんでした。
miss：キャッシュには、このリクエストを満たすために使用できるレスポンスが含まれていませんでした（実装がuri-missとvary-missを区別できない場合に使用します）。
request：キャッシュはリクエストに対して新鮮なレスポンスを選択できましたが、リクエストのセマンティクス（例：Cache-Controlリクエストディレクティブ）により、その使用が許可されませんでした。
stale：キャッシュはリクエストに対してレスポンスを選択できましたが、それは古くなっていました。
partial：キャッシュはリクエストに対して部分的なレスポンスを選択できましたが、要求されたすべての範囲が含まれていませんでした（またはリクエストは完全なレスポンスを求めていました）。
キャッシュに知られている最も具体的な理由をすべきです（SHOULD）。実装可能な範囲で使用してください。[HTTP-CACHING]のセクション4も参照してください。
2.3. fwd-status パラメータ
「fwd-status」の値はIntegerであり、ネクストホップサーバーが転送されたリクエストに応答して返したステータスコード（[HTTP]のセクション15を参照）を示します。fwd-statusパラメータは、fwdが存在する場合にのみ意味があります。fwd-statusが存在しないがfwdパラメータが存在する場合、レスポンスで送信されたステータスコードがデフォルトになります。
このパラメータは、ネクストホップサーバーが条件付きリクエストに304（Not Modified）レスポンスを送信する場合、または範囲リクエストのために206（Partial Content）レスポンスを送信する場合を区別するのに役立ちます。
2.4. ttl パラメータ
「ttl」の値はIntegerであり、キャッシュによって計算されたレスポンスの残りの新鮮度ライフタイム（[HTTP-CACHING]のセクション4.2.1を参照）を整数秒数で示し、キャッシュによってレスポンスヘッダーセクションが送信される時点にできるだけ近く測定されます。これには、ヒューリスティック（[HTTP-CACHING]のセクション4.2.2を参照）、ローカル設定、またはその他の要因を通じてキャッシュによって割り当てられた新鮮度が含まれます。古さを示すために負の値になる可能性があります。
2.5. stored パラメータ
「stored」の値はBooleanであり、キャッシュがレスポンスを保存したかどうかを示します（[HTTP-CACHING]のセクション3を参照）。true値はそれを保存したことを示します。storedパラメータは、fwdが存在する場合にのみ意味があります。
2.6. collapsed パラメータ
「collapsed」の値はBooleanであり、このリクエストが1つ以上の他の転送リクエストと一緒に折りたたまれたかどうかを示します（[HTTP-CACHING]のセクション4を参照）。trueの場合、レスポンスは正常に再利用されました。そうでない場合は、新しいリクエストを行う必要がありました。存在しない場合、リクエストは他のリクエストと折りたたまれませんでした。collapsedパラメータは、fwdが存在する場合にのみ意味があります。
2.7. key パラメータ
「key」の値はStringであり、レスポンスに使用されたキャッシュキーの表現を伝えます（[HTTP-CACHING]のセクション2を参照）。これは実装固有である可能性があることに注意してください。
2.8. detail パラメータ
「detail」の値はStringまたはTokenであり、実装が他のパラメータでキャプチャされていない追加情報（実装固有の状態やその他のキャッシング関連のメトリックなど）を伝えることができます。
例：
Cache-Status: ExampleCache; hit; detail=MEMORY
detailパラメータのセマンティクスは、それを送信したキャッシュに常に固有です。別のキャッシュからのdetailsパラメータが同じ値を共有していても、同じことを意味しない可能性があります。
このパラメータは意図的に制限されています。実装の開発者またはオペレーターが相互運用可能な方法で追加情報を伝える必要がある場合は、拡張パラメータを登録する（セクション4を参照）か、別のヘッダーフィールドを定義することが推奨されます。