Cache-Status HTTPレスポンスヘッダーフィールド

これはインターネット標準化トラック文書です。

本書はインターネット技術標準化委員会（IETF）の成果物です。本書はIETFコミュニティの合意を表しています。公開のために一般レビューを経て、インターネット技術運営指導グループ（IESG）によって承認されています。インターネット標準に関する詳細はRFC 7841のセクション2を参照してください。

本書の現在のステータス、正誤情報、フィードバックの提供方法などは、https://www.rfc-editor.org/info/rfc9211で入手できます。

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

デバッグ（人間および自動ツールの双方を援助するため）を容易にするため、HTTP キャッシュはしばしばレスポンスにヘッダーフィールドを付加して、リクエストをどのように処理したかを説明します。しかしながら、これらのヘッダーフィールドの意味はしばしば不明瞭であり、使われる意味や構文は実装によって異なります。

本仕様はこの目的のために、新しい HTTP レスポンスヘッダーフィールド "Cache-Status" を標準化された構文とセマンティクスで定義します。

Cache-Status HTTP レスポンスヘッダーフィールドは、キャッシュがそのレスポンスおよび対応するリクエストをどのように処理したかを示します。このヘッダーフィールドの構文は [STRUCTURED-FIELDS] に準拠します。

その値は List です。List の各メンバーはリクエストを処理したキャッシュを表します。最初のメンバーはオリジンサーバーに最も近いキャッシュを表し、最後のメンバーはユーザーに最も近いキャッシュ（ユーザーエージェント自身のキャッシュが値を付加する場合を含む）を表します。

キャッシュはいつ Cache-Status ヘッダーフィールドをレスポンスに追加するかを決定します。すべてのレスポンスに追加するものもあれば、特定の設定時や、リクエストにデバッグモードを有効にするヘッダーフィールドが含まれる場合にのみ追加するものもあります。関連するセキュリティ上の考慮事項は セクション6 を参照してください。

中継者は、たとえキャッシュを含んでいても、自身がローカルで生成したレスポンスに Cache-Status メンバーを付加してはなりません（ただし生成されたレスポンスが保存済みレスポンスに基づく場合、例えば 304 (Not Modified) や 206 (Partial Content) のようなレスポンスは例外です）。例えば、プロキシが不正なリクエストにより 400 レスポンスを生成した場合、そのレスポンスはプロキシが生成したものでありオリジンに由来しないため、Cache-Status 値を追加しません。

Cache-Status ヘッダーフィールドに値を追加する際、キャッシュは既存のフィールド値を保持すべきです。これによりリクエストを処理したキャッシュチェーン全体のデバッグが可能になります。

各 List メンバーはそれを挿入したキャッシュを識別し、この識別子は String または Token でなければなりません。デプロイ環境によっては、製品名やサービス名（例: "ExampleCache" や "Example CDN"）、ホスト名（"cache-3.example.com"）、IP アドレス、または生成された文字列が使われることがあります。

リストの各メンバーは、そのキャッシュがリクエストをどのように処理したかを説明するパラメータを持つことができます。これらのパラメータは任意ですが、キャッシュは可能な限り多くの情報を提供することが推奨されます。

本仕様では以下のパラメータを定義します。

Cache-Status: ExampleCache; hit

Cache-Status: ExampleCache; hit; ttl=376

Cache-Status: ExampleCache; hit; ttl=-412

Cache-Status: ExampleCache; fwd=uri-miss

Cache-Status: ExampleCache; fwd=stale; fwd-status=304

Cache-Status: ExampleCache; fwd=uri-miss; collapsed

Cache-Status: ExampleCache; fwd=uri-miss; collapsed=?0

Cache-Status: OriginCache; hit; ttl=1100,
              "CDN Company Here"; hit; ttl=545

Cache-Status: ReverseProxyCache; hit
Cache-Status: ForwardProxyCache; fwd=uri-miss; collapsed; stored
Cache-Status: BrowserCache; fwd=uri-miss

新しい Cache-Status パラメータは "HTTP Cache-Status" レジストリに登録することで定義できます。

登録申請は、RFC 8126 のガイドラインに従い、指定されたエキスパートによってレビューおよび承認されます（[RFC8126]、Section 4.5 を参照）。仕様文書は望ましいが必須ではありません。

• コミュニティのフィードバック
• 値が十分に定義されているかどうか
• 汎用的なパラメータはベンダー固有、アプリケーション固有、デプロイ固有の値よりも優先されます。もしコミュニティで汎用値が合意できない場合、パラメータ名は対応して特定的（例えばベンダーやアプリケーション、デプロイを識別するプレフィックスを付与）にするべきです。

Name:

[Cache-Status パラメータのキー名; 構文要件については Section 3.1.2 を参照してください（[STRUCTURED-FIELDS]）]

Type:

[パラメータ値の Structured Type; Section 3.1.2 を参照（[STRUCTURED-FIELDS]）]

Description:

[パラメータの意味の説明]

Reference:

[利用可能ならばこのパラメータを定義する仕様への参照]

登録申請の送付先の詳細についてはレジストリ（<https://www.iana.org/assignments/http-cache-status>）を参照してください。

IANA は "HTTP Cache-Status" レジストリを <https://www.iana.org/assignments/http-cache-status> に作成し、本仕様のセクション2 で定義された型でそれを初期化しました。関連手続きについては セクション4 を参照してください。

Field name:

Cache-Status

Status:

permanent

Reference:

RFC 9211

攻撃者は Cache-Status に含まれる情報を用いてキャッシュ（および他の構成要素）の挙動を探り、キャッシュを利用する者の活動を推測することができます。Cache-Status ヘッダーフィールド自体がこれらのリスクを新たに生み出すとは限りませんが、攻撃者がこれらのリスクを悪用するのに役立ち得ます。

例えば、キャッシュがレスポンスを保存しているかどうかを知ることで、攻撃者がセンシティブなデータに対するタイミング攻撃を行うのを助ける可能性があります。

さらに、キャッシュキーを公開すると攻撃者がキャッシュキーの変更点を把握でき、キャッシュポイズニング攻撃を助長する可能性があります。詳細は [ENTANGLE] を参照してください。

これらの基礎的なリスクは、暗号化や認証の使用、攻撃者制御下のデータをキャッシュキーに含めないなど、具体的な状況に応じた様々な技術で軽減できます。キーを単に難読化するだけではこのリスクは軽減されない点に注意してください。

このような攻撃の助長を避けるため、Cache-Status ヘッダーフィールドは省略する、クライアントが受け取る権限を持つ場合にのみ送る、あるいは key パラメータなどの機密情報はクライアントが認可されている場合にのみ送る、という対策が考えられます。