2. The Proxy-Status HTTP Field (Proxy-Status HTTP フィールド)

Proxy-Status HTTP レスポンスフィールドは, 中間サーバーがレスポンスとそれに関連するリクエストの処理に関する追加情報を伝達することを可能にします。

その値は List (リスト) です ([STRUCTURED-FIELDS] のセクション3.1を参照)。List の各メンバーは, レスポンスを処理した中間サーバーを表します。最初のメンバーは, オリジンサーバーに最も近い中間サーバーを表し, 最後のメンバーは, ユーザーエージェントに最も近い中間サーバーを表します。

例えば:

Proxy-Status: revproxy1.example.net, ExampleCDN

これは, このレスポンスが最初に revproxy1.example.net (オリジンサーバーに隣接するリバースプロキシ) によって処理され, 次に ExampleCDN によって処理されたことを示します。

中間サーバーは, レスポンスに Proxy-Status フィールドを追加することが適切である時期を決定します。すべてのレスポンスに追加することを決定するものもあれば, 特定の設定がある場合やリクエストにデバッグモードをアクティブにするヘッダーフィールドが含まれている場合にのみ追加するものもあります。

List の各メンバーは, 値を挿入した中間サーバーを識別し, String (文字列) または Token (トークン) のタイプでなければなりません。デプロイメントによっては, これはサービス名 (ただし, ソフトウェアまたはハードウェア製品名ではありません; 例えば, "ExampleCDN" は適切ですが, "ExampleProxy" はデプロイメントを識別しないため適切ではありません), ホスト名 ("proxy-3.example.com"), IP アドレス, または生成された文字列である可能性があります。

各メンバーのパラメータ ([STRUCTURED-FIELDS] のセクション3.1.2に従って) は, その中間サーバーのレスポンスとそれに関連するリクエストの処理に関する追加情報を伝達します; セクション2.1を参照してください。これらのパラメータはすべて任意ですが, 中間サーバーはできるだけ多くの情報を提供することが推奨されます (ただし, そうすることのセキュリティ上の考慮事項についてはセクション4を参照してください)。

Proxy-Status フィールドに値を追加する際, 中間サーバーは, 明示的に削除するように設定されていない限り (例えば, 内部ネットワークの詳細が漏洩するのを防ぐため; セクション4を参照), リクエストを処理する中間サーバーのチェーン全体のデバッグを可能にするために, フィールドの既存のメンバーを保持すべきです。

オリジンサーバーは Proxy-Status フィールドを生成してはなりません。

Proxy-Status は HTTP トレーラーフィールドとして送信してもかまいません。例えば, 中間サーバーがレスポンスをストリーミングしていて, インバウンド接続が突然終了した場合, ヘッダーセクションがすでに送信されているため, Proxy-Status はアウトバウンドメッセージのトレーラーセクションにのみ追加できます。ただし, ユーザーエージェントへのパス上で静かに破棄される可能性があるため (すべてのトレーラーフィールドの場合と同様; [HTTP] のセクション6.5を参照), ヘッダーセクションで送信できない場合を除き, Proxy-Status をトレーラーフィールドとして送信すべきではありません。

受信者がトレーラーフィールドで伝達された Proxy-Status メンバーとヘッダーフィールドで伝達されたメンバーの相対的な順序を再構築できるようにするため, 中間サーバーは, そのメッセージ内に同じメンバー (ただし, パラメータが異なる可能性があります) を持つ Proxy-Status ヘッダーフィールドも生成していない限り, Proxy-Status をトレーラーフィールドとして送信してはなりません。

例えば, 'ThisProxy' として識別されるプロキシが, ヘッダーフィールドを持つレスポンスを受信した場合:

Proxy-Status: SomeOtherProxy

ヘッダーフィールドに独自のエントリを追加します:

Proxy-Status: SomeOtherProxy, ThisProxy

これにより, トレーラーフィールドを追加できるようになります:

Proxy-Status: ThisProxy; error=read_timeout

これにより, ダウンストリームの受信者は, 'SomeOtherProxy' による処理が 'ThisProxy' の前に行われたことを理解できます。

クライアントは, デバッグまたはその他の目的 (例えば, アクセスしやすくするため) のために, Proxy-Status トレーラーフィールド値をヘッダーセクションに昇格させてもかまいません。

2.1. Proxy-Status Parameters (Proxy-Status パラメータ)

Proxy-Status List の各メンバーは, プロキシのレスポンス処理を記述するパラメータを持つことができます。このセクションでは, これらのパラメータについて詳しく説明します。

2.1.1. error

"error" パラメータは, Proxy Error Type (プロキシエラータイプ) (セクション2.3) である Token タイプの値を持ちます; その存在は, 中間サーバーがリクエストのレスポンスを取得する際に問題に遭遇したことを示します。

2.1.2. next-hop

"next-hop" パラメータは, String または Byte Sequence (バイトシーケンス) タイプの値を持ちます; その存在は, 中間サーバーがリクエストを転送するために使用した次のホップを示します。これは, IP アドレスとポート番号, ホスト名, または他の形式の識別子である可能性があります。

2.1.3. next-protocol

"next-protocol" パラメータは, Token または Byte Sequence タイプの値を持ちます; その存在は, 中間サーバーが次のホップに接続するために使用した ALPN プロトコル識別子 [RFC7301] を示します。

2.1.4. received-status

"received-status" パラメータは, Integer (整数) タイプの値を持ちます; その存在は, 中間サーバーが次のホップサーバーから受信した HTTP ステータスコードを示します。パラメータの値は, 100から999までの範囲 (両端を含む) でなければなりません。

このパラメータは, error パラメータが存在しない場合にのみ適用されます。これは, 中間サーバーが次のホップから受信したレスポンスに基づいて独自のレスポンスを生成するが, エラーを生成しない場合に使用することを目的としています。

2.1.5. details

"details" パラメータは, String タイプの値を持ちます; その存在により, プロキシは, このレスポンスに固有であり, より適したパラメータがない追加情報を伝達できます。これには, 実装固有またはデプロイメント固有の情報が含まれる場合があります。

2.2. Defining New Proxy-Status Parameters (新しい Proxy-Status パラメータの定義)

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

登録リクエストは, [RFC8126] のセクション4.5に従って, エキスパートレビューによって審査および承認されます。仕様文書があることが望ましいですが, 必須ではありません。

エキスパートは, リクエストを評価する際に次の要素を考慮すべきです:

コミュニティのフィードバック
値が十分に明確に定義されているかどうか
汎用パラメータは, ベンダー固有, アプリケーション固有, またはデプロイメント固有の値よりも優先されます。コミュニティで汎用値について合意できない場合, パラメータの名前は対応して具体的であるべきです (例えば, ベンダー, アプリケーション, またはデプロイメントを識別する接頭辞を付けるなど)。
パラメータの名前が他の Proxy-Status パラメータ, 新しいまたは既存のエラータイプと競合するか, 混乱を引き起こすか, または将来そうする可能性があるかどうか。

登録リクエストは次のテンプレートを使用すべきです:

名前: [Token タイプの Proxy-Status パラメータの名前]

説明: [パラメータのセマンティクスの説明]

参照: [このパラメータを定義する仕様への参照; 任意]

注記: [任意]

登録リクエストの送信先の詳細については, https://www.iana.org/assignments/http-proxy-status のレジストリを参照してください。