| インターネット技術タスクフォース (IETF) | M. Nottingham |
| Request for Comments: 9209 | Fastly |
| カテゴリー: 標準トラック | P. Sikora |
| ISSN: 2070-1721 | |
| 2022年6月 |
Proxy-Status HTTP レスポンスヘッダーフィールド
概要
本書は、仲介者がレスポンス処理の詳細（生成したエラーを含む）を伝えるための Proxy-Status HTTP レスポンスフィールドを定義します。
本メモの状態
これはインターネット標準トラックの文書です。
この文書は Internet Engineering Task Force (IETF) の成果物です。IETF コミュニティの合意を表しています。公開審査を受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準に関するさらなる情報は RFC 7841 のセクション 2 をご覧ください。
この文書の現状、訂正情報、およびフィードバックの送付方法に関する情報は https://www.rfc-editor.org/info/rfc9209 で入手できます。
Copyright Notice
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.
- 1. 導入
- 2. Proxy-Status HTTP
フィールド
- 2.1. Proxy-Status パラメータ
- 2.2. 新しい Proxy-Status パラメータの定義
- 2.3. プロキシエラーの種類
- 2.3.1. DNS タイムアウト
- 2.3.2. DNS エラー
- 2.3.3. 宛先が見つからない
- 2.3.4. 宛先が利用不可
- 2.3.5. 宛先 IP が禁止されている
- 2.3.6. 宛先 IP が到達不能
- 2.3.7. 接続拒否
- 2.3.8. 接続切断
- 2.3.9. 接続タイムアウト
- 2.3.10. 接続読み取りタイムアウト
- 2.3.11. 接続書き込みタイムアウト
- 2.3.12. 接続上限に到達
- 2.3.13. TLS プロトコルエラー
- 2.3.14. TLS 証明書エラー
- 2.3.15. TLS アラート受信
- 2.3.16. HTTP リクエストエラー
- 2.3.17. HTTP リクエスト拒否
- 2.3.18. HTTP 不完全なレスポンス
- 2.3.19. HTTP レスポンスヘッダ部が大きすぎる
- 2.3.20. HTTP レスポンスヘッダフィールド行が大きすぎる
- 2.3.21. HTTP レスポンスボディが大きすぎる
- 2.3.22. HTTP レスポンストレーラー部が大きすぎる
- 2.3.23. HTTP レスポンストレーラーフィールド行が大きすぎる
- 2.3.24. HTTP レスポンス転送符号化エラー
- 2.3.25. HTTP レスポンス内容符号化エラー
- 2.3.26. HTTP レスポンスタイムアウト
- 2.3.27. HTTP Upgrade 失敗
- 2.3.28. HTTP プロトコルエラー
- 2.3.29. プロキシ内部レスポンス
- 2.3.30. プロキシ内部エラー
- 2.3.31. プロキシ構成エラー
- 2.3.32. プロキシループ検出
- 2.4. 新しいプロキシエラー種別の定義
- 3. IANA 考慮事項
- 4. セキュリティ考慮事項
- 5. 参考文献
- 著者の連絡先
1. 導入
HTTP の仲介者（Section 3.7 of [HTTP] 参照） — フォワードプロキシとゲートウェイ（いわゆる「リバースプロキシ」）の両方を含む — は、HTTP デプロイメントにおいてますます重要な存在になっています。特に、リバースプロキシやコンテンツ配信ネットワーク（CDN）は多くのウェブサイトの重要なインフラを構成しています。
通常、HTTP 仲介者はリクエストをオリジンサーバーへ転送し（インバウンド）、その後レスポンスをクライアントへ転送します（アウトバウンド）。しかし、インバウンドサーバーからレスポンスが取得される前にエラーが発生した場合、レスポンスはしばしば仲介者自身によって生成されます。
HTTP はこれらの種類のエラーに対していくつかのステータスコード（例えば 502 (Bad Gateway) や 504 (Gateway Timeout)）を用意しています。しかし、経験上、デバッグを助けクライアントに何が起きたかを伝えるためにより多くの情報が必要であることが示されています。加えて、仲介者は時にレスポンスを生成していない場合でも、その処理に関する追加情報を伝えたいことがあります。
これらの用途を可能にするために、セクション 2 は、仲介者がレスポンスの処理の詳細を伝えられるようにする新しい HTTP レスポンスフィールドを定義します。セクション 2.1 は仲介者がフィールドに追加できる情報を列挙し、これは セクション 2.2 に従って拡張できます。セクション 2.3 は、プロキシがリクエストのレスポンスを取得する際に問題に遭遇した場合に使用するエラー種別のセットを定義します。これらも同様に セクション 2.4 に従って拡張可能です。
1.1. 表記規約
本書内の語句 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、すべて大文字で表示される場合に限り、BCP 14（[RFC2119]）および [RFC8174] に従って解釈されます。
本書は構文と解析を指定するために、Section 3 of [STRUCTURED-FIELDS] からの用語（List、String、Token、Integer、および Byte Sequence）を使用します。
本仕様では "proxy" はフォワードプロキシとリバースプロキシ（ゲートウェイ）の両方を示すために使用されます。"Next hop" はリクエストに対してオリジンサーバーへ向かう方向の接続を示します。
2. Proxy-Status HTTP フィールド
Proxy-Status HTTP レスポンスフィールドにより、仲介者はレスポンスおよびそれに関連するリクエストの処理に関する追加情報を伝達できます。
その値は List です（Section 3.1 of [STRUCTURED-FIELDS] 参照）。リストの各要素はレスポンスを処理した仲介者を表します。最初の要素はオリジンサーバーに最も近い仲介者を、最後の要素はユーザーエージェントに最も近い仲介者を表します。
例えば：
Proxy-Status: revproxy1.example.net, ExampleCDN
は、このレスポンスが最初に revproxy1.example.net（オリジンサーバーに近いリバースプロキシ）により処理され、その後 ExampleCDN によって処理されたことを示します。
仲介者は、いつ Proxy-Status フィールドをレスポンスに追加するかを判断します。ある仲介者はすべてのレスポンスに追加することを選ぶかもしれませんし、特定の設定がされた場合やデバッグモードを有効にするヘッダーフィールドがあった場合にのみ追加することを選ぶかもしれません。
リストの各メンバーはその値を挿入した仲介者を識別し、型は String または Token でなければなりません。展開により、これはサービス名（ソフトウェアやハードウェア製品名ではない、デプロイメントを特定するもの；例："ExampleCDN" は適切、"ExampleProxy" は展開を特定しないため適切でない）、ホスト名（"proxy-3.example.com"）、IP アドレス、または生成された文字列であり得ます。
各メンバーのパラメータ（Section 3.1.2 of [STRUCTURED-FIELDS] 参照）は、その仲介者のレスポンスおよび関連リクエストの処理に関する追加情報を伝えます。詳細は セクション 2.1 を参照してください。これらのパラメータはすべて OPTIONAL ですが、仲介者は可能な限り多くの情報を提供することが奨励されます（ただし提供に際しては セクション 4 のセキュリティ考慮事項を参照してください）。
値を Proxy-Status フィールドに追加する際、仲介者は既存のメンバーを保持して、リクエストを処理した仲介者チェーン全体のデバッグを可能にするべきです（内部ネットワークの詳細が漏れるのを防ぐために明示的に削除するよう設定されている場合は除く；詳細は セクション 4 を参照）。
オリジンサーバーは Proxy-Status フィールドを生成してはなりません（MUST NOT）。
Proxy-Status は HTTP トレーラーフィールドとして送信しても MAY です。例えば、仲介者がレスポンスをストリーミングしていてインバウンド接続が突然切断された場合、Proxy-Status はヘッダ部が既に送信されているためアウトバウンドメッセージのトレーラー部に追加されるしかありません。ただし、トレーラーは経路上で黙って破棄される可能性があるため（すべてのトレーラーフィールドについて当てはまる；Section 6.5 of [HTTP] 参照）、トレーラーとして送信するのはヘッダ部で送信できない場合に限り SHOULD NOT です。
トレーラーフィールドで伝えられた Proxy-Status メンバーとヘッダーフィールドで伝えられたメンバーの相対順序を受信者が再構築できるようにするため、仲介者は同じメンバーを含む Proxy-Status ヘッダーフィールドをそのメッセージで生成していない限り、Proxy-Status をトレーラーとして送信してはなりません（MUST NOT）。
例えば、'ThisProxy' と識別されるプロキシが以下のヘッダーフィールドを持つレスポンスを受け取った場合：
Proxy-Status: SomeOtherProxy
それは自身のエントリをヘッダーフィールドに追加します：
Proxy-Status: SomeOtherProxy, ThisProxy
これによりトレーラーフィールドを次のように追加することができます：
Proxy-Status: ThisProxy; error=read_timeout
これにより下流の受信者は 'SomeOtherProxy' の処理が 'ThisProxy' より前に行われたことを理解できます。
クライアントは次の手順に従って Proxy-Status トレーラーフィールドをヘッダーフィールドへ昇格させることが MAY です：
-
Proxy-Status トレーラーフィールド値の各メンバー trailer_member について：
- header_member を Proxy-Status ヘッダーフィールド値の最初（左端）の値とし、String または Token をパラメータを考慮せず文字ごとに比較する。
- 一致する header_member が見つからなければ、次の trailer_member の処理へ進む。
- header_member をその全体（任意のパラメータを含む）で trailer_member に置き換える。
- Proxy-Status トレーラーフィールドが空であれば削除する。
2.1. Proxy-Status パラメータ
本節は Proxy-Status フィールドのメンバーで使用できるパラメータを列挙します。認識されないパラメータは MUST 無視されなければなりません。
2.1.1. error
error パラメータの値は Token で、プロキシエラー種別を表します。存在する場合、仲介者がこのレスポンスを取得する際に問題に遭遇したことを示します。
一部のプロキシエラー種別の存在は、レスポンスがオリジンサーバーから転送されたのではなく仲介者自身によって生成されたことを示します。例えば、オリジンサーバーに接続できないためにプロキシが自身でレスポンスを作成しなければならなかった場合などです。
他のプロキシエラー種別は、オリジンサーバーや他のインバウンドサーバーによって生成された（部分的な）レスポンスに追加される場合があります。例えば、フォワード接続が突然閉じた場合、仲介者は適切なエラーを伴う Proxy-Status をトレーラーフィールドとして追加するかもしれません。
'Response only generated by intermediaries' 値が 'true' のプロキシエラー種別は、仲介者が生成するレスポンスでのみ発生し得ることを示します。値が 'false' の場合、そのレスポンスは仲介者またはインバウンドサーバーのいずれかによって生成される可能性があります。
例えば：
HTTP/1.1 504 Gateway Timeout Proxy-Status: ExampleCDN; error=connection_timeout
は、この 504 レスポンスが ExampleCDN によって、フォワード時の接続タイムアウトのために生成されたことを示します。
あるいは：
HTTP/1.1 429 Too Many Requests Proxy-Status: r34.example.net; error=http_request_error, ExampleCDN
は、この 429 (Too Many Requests) レスポンスが CDN やオリジンではなく r34.example.net によって生成されたことを示します。
エラー用パラメータを送信する場合、エラー状態を正確に表す最も具体的なプロキシエラー種別を送信することが SHOULD です。適切な種別が定義されていない場合、proxy_internal_error や http_protocol_error のような一般的なエラー種別を使用できます。それらも適切でない場合は、新しいプロキシエラー種別を登録することを検討してください（セクション 2.4 を参照）。
各プロキシエラー種別には推奨される HTTP ステータスコードがあります。error を含む HTTP レスポンスを生成する場合、その HTTP ステータスコードは推奨されたコードに設定することが SHOULD です。ただし、以前の動作との互換性のためや既にステータスコードが送信されている場合など、別のステータスコードを使用する状況もあり得ます。
プロキシエラー種別は、該当する種別とともに使用する任意の追加パラメータを定義することができます。これらの使用はすべて任意です。その結果、追加パラメータが定義されていないプロキシエラー種別とともに使用された場合、そのパラメータは無視されます。
2.1.2. next-hop
next-hop パラメータの値は、このレスポンスを取得するために選択（および使用された場合は接続された）された仲介者またはオリジンサーバーを識別する String または Token です。ホスト名、IP アドレス、エイリアスなどである可能性があります。
例えば：
Proxy-Status: cdn.example.org; next-hop=backend.example.org:8001
は、cdn.example.org がこのリクエストの next hop として backend.example.org:8001 を使用したことを示します。
2.1.3. next-protocol
next-protocol パラメータの値は、仲介者がこのレスポンスを取得するために next hop に接続する際に使用した Application-Layer Protocol Negotiation (ALPN) のプロトコル識別子を示します（[RFC7301] 参照）。
値は TLS ALPN Protocol ID を表す Token または Byte Sequence であることが MUST です（参照: <https://www.iana.org/assignments/tls-extensiontype-values#alpn-protocol-ids>）。プロトコル識別子が ASCII エンコードで Token として表現可能な場合、その形式を使用することが MUST です。
例えば：
Proxy-Status: "proxy.example.org"; next-protocol=h2
ここで ALPN 識別子は使用中のプロトコルを識別するために使われており、実際にプロトコルネゴシエーションで用いられたかどうかは問わない点に注意してください。
2.1.4. received-status
received-status パラメータの値は、仲介者がこのレスポンスを取得する際に next-hop サーバーから受け取った HTTP ステータスコードを示します。
値は MUST Integer でなければなりません。
例えば：
Proxy-Status: ExampleCDN; received-status=200
2.1.5. details
details パラメータの値は、他に記録されていない追加情報を含む String です。これは実装固有やデプロイメント固有の情報を含めることができます。
例えば：
Proxy-Status: proxy.example.net; error="http_protocol_error";
details="Malformed response header: space before colon"
2.2. 新しい Proxy-Status パラメータの定義
新しい Proxy-Status パラメータは "HTTP Proxy-Status Parameters" レジストリに登録することで定義できます。
登録要求は Expert Review によって審査・承認されます（[RFC8126]、Section 4.5 参照）。仕様文書は歓迎されますが必須ではありません。
専門家は登録要求を評価する際に次の点を考慮すべきです：
- コミュニティのフィードバック
- 値が十分に定義されているか
- 汎用的なパラメータはベンダー固有、アプリケーション固有、デプロイメント固有の値より好まれる。汎用的な値がコミュニティで合意できない場合、パラメータ名は対応して特定的であるべき（例：ベンダーやアプリケーションを識別するプレフィックスを付ける）
- パラメータ名は "HTTP Proxy Error Types" レジストリに登録された追加パラメータと衝突しないこと
登録要求は次のテンプレートを使用してください：
- Name:
- [Proxy-Status パラメータのキーに一致する名前]
- Description:
- [パラメータの意味と値の説明]
- Reference:
- [このパラメータを定義する仕様への参照；任意]
登録要求の送付先の詳細は <https://www.iana.org/assignments/http-proxy-status> のレジストリを参照してください。
2.3. プロキシエラーの種類
本節は本書で定義されるプロキシエラー種別を列挙します。新しいプロキシエラー種別の定義については セクション 2.4 を参照してください。
実装がすべてのプロキシエラー種別を生成するとは限らない点に注意してください。以下の種類は実装内の既存の状態にマッピングするよう設計されており、すべての実装に当てはまるとは限りません。
2.3.1. DNS タイムアウト
- Name:
- dns_timeout
- Description:
- 仲介者が next-hop ホスト名の IP アドレスを見つけようとした際にタイムアウトが発生した。
- Extra Parameters:
- なし
- Recommended HTTP Status Code:
- 504
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.2. DNS エラー
- Name:
- dns_error
- Description:
- 仲介者が next-hop ホスト名の IP アドレスを見つけようとした際に DNS エラーが発生した。
- Extra Parameters:
-
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.3. 宛先が見つからない
- Name:
- destination_not_found
- Description:
- 仲介者がこのリクエストに使用すべき適切なネクストホップを判断できない（例えば、設定されていない）状況。これは通常、"backend" サーバーを識別するための明示的な構成を必要とするゲートウェイに特有のエラーである点に注意すること。フォワードプロキシはオリジンサーバーを識別するためにインバンド情報を使用する。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 500
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.5. 宛先 IP が禁止されている
- Name:
- destination_ip_prohibited
- Description:
- 仲介者がネクストホップの IP アドレスへの接続を禁止するよう設定されている。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.6. 宛先 IP が到達不能
- Name:
- destination_ip_unroutable
- Description:
- 仲介者がネクストホップの IP アドレスへの経路を見つけられない。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.7. 接続拒否
- Name:
- connection_refused
- Description:
- 仲介者からネクストホップへの接続が拒否された。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.8. 接続切断
- Name:
- connection_terminated
- Description:
- 仲介者とネクストホップ間の接続が、完全なレスポンスを受け取る前に切断された。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.9. 接続タイムアウト
- Name:
- connection_timeout
- Description:
- 仲介者のネクストホップへの接続試行がタイムアウトした。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 504
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.10. 接続読み取りタイムアウト
- Name:
- connection_read_timeout
- Description:
- 仲介者が接続上（例えばレスポンスの一部）でデータを期待していたが、設定された時間内に新しいデータを受け取らなかった。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 504
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.11. 接続書き込みタイムアウト
- Name:
- connection_write_timeout
- Description:
- 仲介者が接続へデータを書き込もうとしたが、（例えばバッファが満杯などのために）書き込めなかった。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 504
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.12. 接続上限に到達
- Name:
- connection_limit_reached
- Description:
- 仲介者がネクストホップへの接続数を制限するよう設定されており、その制限を超えた。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 503
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.13. TLS プロトコルエラー
- Name:
- tls_protocol_error
- Description:
- 仲介者がネクストホップと通信する際に TLS エラーに遭遇した（ハンドシェイク中またはその後のいずれか）。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
- Notes:
- TLS アラートを受信した場合には適切ではない（その場合は tls_alert_received を参照）。
2.3.14. TLS 証明書エラー
- Name:
- tls_certificate_error
- Description:
- 仲介者がネクストホップから提示された証明書の検証中にエラーに遭遇した。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.15. TLS アラート受信
- Name:
- tls_alert_received
- Description:
- 仲介者がネクストホップから TLS アラートを受信した。
- Extra Parameters:
-
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.16. HTTP リクエストエラー
- Name:
- http_request_error
- Description:
- 仲介者がオリジンに代わってクライアント向けの（4xx）レスポンスを生成している。該当するステータスコードには（例として）400, 403, 405, 406, 408, 411, 413, 414, 415, 416, 417, 429 などがある。
- Extra Parameters:
-
- status-code:
- 生成されたステータスコードを含む Integer。
- status-phrase:
- 生成されたステータスフレーズを含む String。
- Recommended HTTP Status Code:
- 該当する 4xx ステータスコード
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
- Notes:
- この種別は、仲介者が生成したレスポンスとオリジンが生成したレスポンスを区別するのに役立つ。
2.3.17. HTTP リクエスト拒否
- Name:
- http_request_denied
- Description:
- 仲介者がその構成および／またはポリシーに基づいて HTTP リクエストを拒否した。リクエストはネクストホップに転送されていない。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 403
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.18. HTTP 不完全なレスポンス
- Name:
- http_response_incomplete
- Description:
- 仲介者がネクストホップからのレスポンスを不完全な形で受信した。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.19. HTTP レスポンスヘッダ部が大きすぎる
- Name:
- http_response_header_section_size
- Description:
- 仲介者が受信したレスポンスのヘッダ部が大きすぎると判断した。
- Extra Parameters:
-
- header-section-size:
- 受信したヘッダの大きさを示す Integer。完全でない場合もあり得る（仲介者が追加データを破棄または拒否した可能性がある）。
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.20. HTTP レスポンスヘッダフィールド行が大きすぎる
- Name:
- http_response_header_size
- Description:
- 仲介者が受信したレスポンスに含まれる個々のヘッダフィールド行のうち、ある行が大きすぎると判断した。
- Extra Parameters:
-
- header-name:
- エラーを引き起こしたヘッダフィールドの名前を示す String。
- header-size:
- エラーを引き起こしたヘッダフィールドのサイズを示す Integer。
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.21. HTTP レスポンスボディが大きすぎる
- Name:
- http_response_body_size
- Description:
- 仲介者が受信したレスポンスの本文が大きすぎると判断した。
- Extra Parameters:
-
- body-size:
- 受信した本文の大きさを示す Integer。完全でない場合もあり得る（仲介者が追加データを破棄または拒否した可能性がある）。
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.22. HTTP レスポンストレーラー部が大きすぎる
- Name:
- http_response_trailer_section_size
- Description:
- 仲介者が受信したレスポンスのトレーラー部が大きすぎると判断した。
- Extra Parameters:
-
- trailer-section-size:
- 受信したトレーラーの大きさを示す Integer。完全でない場合もあり得る（仲介者が追加データを破棄または拒否した可能性がある）。
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.23. HTTP レスポンストレーラーフィールド行が大きすぎる
- Name:
- http_response_trailer_size
- Description:
- 仲介者が受信したレスポンスに含まれる個々のトレーラーフィールド行のうち、ある行が大きすぎると判断した。
- Extra Parameters:
-
- trailer-name:
- エラーを引き起こしたトレーラーフィールドの名前を示す String。
- trailer-size:
- エラーを引き起こしたトレーラーフィールドのサイズを示す Integer。
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.24. HTTP レスポンス転送符号化エラー
- Name:
- http_response_transfer_coding
- Description:
- 仲介者がレスポンスの transfer coding のデコード中にエラーに遭遇した。
- Extra Parameters:
-
- coding:
- エラーの原因となった具体的なコーディングを含む Token（"HTTP Transfer Coding Registry" からの値）。
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.25. HTTP レスポンス内容符号化エラー
- Name:
- http_response_content_coding
- Description:
- 仲介者がレスポンスの content coding のデコード中にエラーに遭遇した。
- Extra Parameters:
-
- coding:
- エラーの原因となった具体的なコーディングを含む Token（"HTTP Content Coding Registry" からの値）。
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.26. HTTP レスポンスタイムアウト
- Name:
- http_response_timeout
- Description:
- 仲介者が完全なレスポンスを待つ際に設定された時間制限に達した。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 504
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.27. HTTP Upgrade 失敗
- Name:
- http_upgrade_failed
- Description:
- 仲介者とネクストホップ間での HTTP バージョンのアップグレード交渉が失敗した。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.28. HTTP プロトコルエラー
- Name:
- http_protocol_error
- Description:
- 仲介者がネクストホップとの通信で HTTP プロトコルエラーに遭遇した。より具体的なエラーが定義されていない場合にのみ使用すべきである。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- false
- Reference:
- RFC 9209
2.3.29. プロキシ内部レスポンス
- Name:
- proxy_internal_response
- Description:
- 仲介者がネクストホップに接続を試みずに自身でレスポンスを生成した。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- レスポンスに最も適切なステータスコード
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.30. プロキシ内部エラー
- Name:
- proxy_internal_error
- Description:
- 仲介者がオリジンに関連しない内部エラーに遭遇した。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 500
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.31. プロキシ構成エラー
- Name:
- proxy_configuration_error
- Description:
- 仲介者がその構成に関するエラーに遭遇した。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 500
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.32. プロキシループ検出
- Name:
- proxy_loop_detected
- Description:
- 仲介者がリクエストを自身に転送しようとした、または別の手段（例: [RFC8586]）によりループが検出された。
- Extra Parameters:
- None
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.4. 新しいプロキシエラー種別の定義
新しいプロキシエラー種別は "HTTP Proxy Error Types" レジストリに登録することで定義できます。
登録要求は Expert Review によって審査・承認されます（[RFC8126]、Section 4.5 参照）。仕様文書は歓迎されますが必須ではありません。
専門家は登録要求を評価する際に次の点を考慮すべきです：
- コミュニティのフィードバック
- 値が十分に定義されているか
- 汎用的な種別はベンダー固有、アプリケーション固有、デプロイメント固有の値より好まれる。汎用的な値が合意できない場合、種別名はそれに応じて特定的であるべき（例：ベンダー、アプリケーション、デプロイメントを識別するプレフィックスを付与する）
- 追加パラメータは登録済みの Proxy-Status パラメータと衝突しないこと
登録要求は次のテンプレートを使用してください：
- Name:
- [Token 型のプロキシエラー種別名]
- Description:
- [そのプロキシエラー種別を生成する条件の記述]
- Extra Parameters:
- [0 個以上のオプションパラメータとそれらの許容される Structured Type(s)]
- Recommended HTTP Status Code:
- [このエントリに適切な HTTP ステータスコード]
- Response Only Generated by Intermediaries:
- ['true' または 'false']
- Reference:
- [このエラー種別を定義する仕様への参照；任意]
- Notes:
- [任意]
プロキシエラー種別が仲介者自身が生成しないレスポンスでも発生し得る場合（例：フォワード接続からレスポンスをストリーミング中にエラーが検出され、Proxy-Status トレーラーフィールドが追加されるような場合）、'Response only generated by intermediaries' は 'false' とするべきです。仲介者が生成するレスポンスでのみ発生する種別は 'true' とするべきです。
登録要求の送付先の詳細は <https://www.iana.org/assignments/http-proxy-status> のレジストリを参照してください。
3. IANA の考慮事項
IANA は "HTTP Proxy-Status Parameters" レジストリと "HTTP Proxy Error Types" レジストリを <https://www.iana.org/assignments/http-proxy-status> に作成し、セクション 2.1 および 2.3 で定義された型でそれらを初期化した（関連手続きは 2.2 および 2.4 を参照）。
さらに、次のエントリが "Hypertext Transfer Protocol (HTTP) Field Name Registry" に追加されました：
- Field name:
- Proxy-Status
- Status:
- permanent
- Specification document(s):
- RFC 9209
- Comments:
4. セキュリティに関する考慮事項
Proxy-Status を使用する際の主要なセキュリティ上の懸念の一つは、攻撃者を助ける可能性のある情報が漏洩することである。例えば、仲介者の構成やバックエンドのトポロジに関する情報が露出すると、攻撃者は高トラフィックや不正な入力に対する準備ができていないバックエンドサービスを直接攻撃できるようになる。ある情報は認可された当事者だけに公開すべき場合がある。
したがって、Proxy-Status フィールドを生成するかどうか、またその中にどの情報を含めるかを決定する際には注意が必要である。仲介者はどのレスポンスにも Proxy-Status フィールドを生成する義務はなく、リクエスト属性（例：認証トークン、IP アドレス）に基づいて条件付きで生成することができる点に注意する。
同様に、すべてのパラメータの生成は任意であり、フィールド自体の生成も任意である。また、フィールドの内容は検証されない；仲介者は暗号化チャネルでリクエストを送信したと主張するが実際にはそうしていない、といったことが起こり得る。
5. 参考文献
5.1. 規範的参考文献
- [HTTP]
- Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
- [RFC2119]
- Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
- [RFC7301]
- Friedl, S., Popov, A., Langley, A., and E. Stephan, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
- [RFC8126]
- Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
- [RFC8174]
- Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8499]
- Hoffman, P., Sullivan, A., and K. Fujiwara, “DNS Terminology”, BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
- [RFC8914]
- Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, “Extended DNS Errors”, RFC 8914, DOI 10.17487/RFC8914, October 2020, <https://www.rfc-editor.org/info/rfc8914>.
- [STRUCTURED-FIELDS]
- Nottingham, M. and P-H. Kamp, “Structured Field Values for HTTP”, RFC 8941, DOI 10.17487/RFC8941, March 2021, <https://www.rfc-editor.org/info/rfc8941>.
- [TLS]
- Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
5.2. 参考資料
- [RFC8586]
- Ludin, S., Nottingham, M., and N. Sullivan, “Loop Detection in Content Delivery Networks (CDNs)”, RFC 8586, DOI 10.17487/RFC8586, April 2019, <https://www.rfc-editor.org/info/rfc8586>.