| 互联网工程任务组 (IETF) | M. Nottingham |
| 请求评注: 9209 | Fastly |
| 类别: 标准轨道 | P. Sikora |
| ISSN: 2070-1721 | |
| 2022年6月 |
代理状态 HTTP 响应头字段
摘要
本文档定义了 Proxy-Status HTTP 响应字段，用于传递中间节点在响应处理过程中的详细信息，包括生成的错误。
本备忘录的状态
这是一个互联网标准轨道文档。
本文档是互联网工程任务组 (IETF) 的成果，代表了 IETF 社区的共识。它已接受公开审查并已获得互联网工程指导组 (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 升级失败
- 2.3.28. HTTP 协议错误
- 2.3.29. 代理内部响应
- 2.3.30. 代理内部错误
- 2.3.31. 代理配置错误
- 2.3.32. 检测到代理循环
- 2.4. 定义新的代理错误类型
- 3. IANA 注意事项
- 4. 安全注意事项
- 5. 参考文献
- 作者地址
1. 介绍
HTTP 中间节点（参见 第 3.7 节 的 [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]。
本文档使用来自 [STRUCTURED-FIELDS] 第 3 节 的术语来指定语法和解析：List、String、Token、Integer 和 Byte Sequence。
注意，在本规范中，“proxy” 用于指代正向和反向代理（即网关）。“next hop” 表示通向请求的源服务器方向上的连接。
2. 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 的每个成员标识插入该值的中间节点，并且 MUST 为 String 或 Token 类型。根据部署情况，这可能是服务名（但不得为软件或硬件产品名；例如，“ExampleCDN” 是合适的，但 “ExampleProxy” 不合适，因为它不能标识部署）、主机名（“proxy-3.example.com”）、IP 地址或生成的字符串。
每个成员的参数（参见 [STRUCTURED-FIELDS] 第 3.1.2 节）传达关于该中间节点处理响应及其相关请求的附加信息；见 第 2.1 节。尽管这些参数均为 OPTIONAL，仍鼓励中间节点尽可能提供更多信息（但在这样做时请参见 第 4 节 的安全注意事项）。
在向 Proxy-Status 字段添加值时，中间节点 SHOULD 保留字段中已有的成员，以便调试处理该请求的整个中间节点链，除非明确配置为移除它们（例如，为防止内部网络细节泄露；参见 第 4 节）。
源服务器 MUST NOT 生成 Proxy-Status 字段。
Proxy-Status MAY 作为 HTTP trailer 字段发送。例如，如果中间节点在流式传输响应时入站连接突然终止，Proxy-Status 只能附加到出站消息的尾部部分，因为头部部分已发送。然而，由于尾部字段可能在传输途中被静默丢弃（如所有 trailer 字段一样；参见 [HTTP] 第 6.5 节），因此除非无法在头部发送，否则 Proxy-Status SHOULD NOT 作为 trailer 字段发送。
为允许接收者重建在头部字段中传达的 Proxy-Status 成员与在尾部字段中传达的成员之间的相对顺序，中间节点 MUST NOT 发送作为尾部字段的 Proxy-Status，除非它也在该消息中生成了包含相同成员（虽然参数可能不同）的 Proxy-Status 头部字段。
例如，标识为 'ThisProxy' 的代理接收到包含头字段的响应：
Proxy-Status: SomeOtherProxy
会将其自身条目添加到头字段：
Proxy-Status: SomeOtherProxy, ThisProxy
从而允许它附加一个尾部字段：
Proxy-Status: ThisProxy; error=read_timeout
这样下游接收者就能理解 'SomeOtherProxy' 的处理发生在 'ThisProxy' 之前。
客户端 MAY 通过以下步骤将 Proxy-Status 尾部字段提升为头部字段：
-
对于 Proxy-Status 尾部字段值的每个成员 trailer_member：
- 令 header_member 为 Proxy-Status 头部字段值的第一个（最左）值，按字符逐个比较 String 或 Token，而不考虑参数。
- 如果未找到匹配的 header_member，则继续处理下一个 trailer_member。
- 用 trailer_member 完整替换 header_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（请求过多）响应由 r34.example.net 生成，而不是由 CDN 或源服务器生成。
发送 error 参数时，应发送最具体的代理错误类型，前提是它能准确表示错误情况。当没有合适的代理错误类型时，可使用一些通用错误类型（例如 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 在此请求中使用了 backend.example.org:8001 作为下一跳。
2.1.3. next-protocol
next-protocol 参数的值指示中间节点在连接到下一跳以获取此响应时使用的应用层协议的 ALPN 标识符 [RFC7301]。
该值 MUST 为表示 TLS ALPN Protocol ID 的 Token 或 Byte Sequence（见 <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 参数的值指示中间节点在从下一跳服务器获取此响应时所接收到的 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” 注册表中注册来定义。
注册请求由专家审查并批准，依据 [RFC8126]（第 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:
- 中间节点尝试为下一跳主机名查找 IP 地址时遇到超时。
- Extra Parameters:
- 无
- Recommended HTTP Status Code:
- 504
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.2. DNS 错误
2.3.3. 目标未找到
- 名称:
- destination_not_found
- 描述:
- 中介无法确定用于此请求的合适下一跳；例如，可能未配置。请注意，该错误特定于网关，网关通常需要特定配置以识别“后端”服务器；正向代理使用带内信息来识别源服务器。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 500
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.5. 目标 IP 被禁止
- 名称:
- destination_ip_prohibited
- 描述:
- 中介被配置为禁止与下一跳 IP 地址建立连接。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.6. 目标 IP 无路由
- 名称:
- destination_ip_unroutable
- 描述:
- 中介找不到到下一跳 IP 地址的路由。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.7. 连接被拒绝
- 名称:
- connection_refused
- 描述:
- 中介到下一跳的连接被拒绝。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.8. 连接终止
- 名称:
- connection_terminated
- 描述:
- 在接收到完整响应之前，中介到下一跳的连接被关闭。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.9. 连接超时
- 名称:
- connection_timeout
- 描述:
- 中介尝试与下一跳建立连接的操作超时。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 504
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.10. 连接读取超时
- 名称:
- connection_read_timeout
- 描述:
- 中介在某连接上（例如响应的一部分）期待数据，但在配置的时间限制内未收到任何新数据。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 504
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.11. 连接写入超时
- 名称:
- connection_write_timeout
- 描述:
- 中介尝试向连接写入数据但无法写入（例如，因为其缓冲区已满）。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 504
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.12. 达到连接上限
- 名称:
- connection_limit_reached
- 描述:
- 中介被配置为限制其到下一跳的连接数量，该限制已被超过。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 503
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.13. TLS 协议错误
- 名称:
- tls_protocol_error
- 描述:
- 中介在与下一跳通信时遇到 TLS 错误，可能是在握手期间或之后发生。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
- 注释:
- 当收到 TLS 警报时不适用；参见 tls_alert_received。
2.3.14. TLS 证书错误
- 名称:
- tls_certificate_error
- 描述:
- 中介在验证下一跳出示的证书时遇到错误。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.15. 收到 TLS 警报
- 名称:
- tls_alert_received
- 描述:
- 中介从下一跳接收到 TLS 警报。
- 额外参数:
-
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.16. HTTP 请求错误
- 名称:
- http_request_error
- 描述:
- 中介代表源生成客户端（4xx）响应。适用的状态码包括（但不限于）400、403、405、406、408、411、413、414、415、416、417 和 429。
- 额外参数:
-
- status-code:
- An Integer containing the generated status code.
- status-phrase:
- A String containing the generated status phrase.
- 建议的 HTTP 状态码:
- 适用的 4xx 状态码
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
- 注释:
- 此类型有助于区分由中介生成的响应与由源生成的响应。
2.3.17. HTTP 请求被拒绝
- 名称:
- http_request_denied
- 描述:
- 中介基于其配置和/或策略设置拒绝了 HTTP 请求。该请求未被转发到下一跳。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 403
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.18. HTTP 响应不完整
- 名称:
- http_response_incomplete
- 描述:
- 中介从下一跳收到的对请求的响应不完整。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.19. HTTP 响应头部部分过大
- 名称:
- http_response_header_section_size
- 描述:
- 中介收到的响应的头部部分被认为过大。
- 额外参数:
-
- header-section-size:
- An Integer indicating how large the received headers were. Note that they might not be complete; i.e., the intermediary may have discarded or refused additional data.
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.20. HTTP 响应头字段行过长
- 名称:
- http_response_header_size
- 描述:
- 中介收到的响应包含被认为过大的单个头字段行。
- 额外参数:
-
- header-name:
- A String indicating the name of the header field that triggered the error.
- header-size:
- An Integer indicating the size of the header field that triggered the error.
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.21. HTTP 响应体过大
- 名称:
- http_response_body_size
- 描述:
- 中介收到的响应体被认为过大。
- 额外参数:
-
- body-size:
- An Integer indicating how large the received body was. Note that it may not have been complete; i.e., the intermediary may have discarded or refused additional data.
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.22. HTTP 响应尾部部分过大
- 名称:
- http_response_trailer_section_size
- 描述:
- 中介收到的响应的尾部部分被认为过大。
- 额外参数:
-
- trailer-section-size:
- An Integer indicating how large the received trailers were. Note that they might not be complete; i.e., the intermediary may have discarded or refused additional data.
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.23. HTTP 响应尾部字段行过长
- 名称:
- http_response_trailer_size
- 描述:
- 中介收到的响应包含被认为过大的单个尾部字段行。
- 额外参数:
-
- trailer-name:
- A String indicating the name of the trailer field that triggered the error.
- trailer-size:
- An Integer indicating the size of the trailer field that triggered the error.
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.24. HTTP 响应传输编码错误
- 名称:
- http_response_transfer_coding
- 描述:
- 中介在解码响应的传输编码时遇到错误。
- 额外参数:
-
- coding:
- A Token containing the specific coding (from the "HTTP Transfer Coding Registry") that caused the error.
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.25. HTTP 响应内容编码错误
- 名称:
- http_response_content_coding
- 描述:
- 中介在解码响应的内容编码时遇到错误。
- 额外参数:
-
- coding:
- A Token containing the specific coding (from the "HTTP Content Coding Registry") that caused the error.
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.26. HTTP 响应超时
- 名称:
- http_response_timeout
- 描述:
- 中介在等待完整响应时达到配置的时间限制。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 504
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.27. HTTP 升级失败
- 名称:
- http_upgrade_failed
- 描述:
- 中介与下一跳之间协商 HTTP 版本升级的过程失败。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.28. HTTP 协议错误
- 名称:
- http_protocol_error
- 描述:
- 中介在与下一跳通信时遇到 HTTP 协议错误。仅在没有更具体的错误类型定义时使用此错误。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- false
- 参考文献:
- RFC 9209
2.3.29. 代理内部响应
- 名称:
- proxy_internal_response
- 描述:
- 中介自行生成了响应，并未尝试连接下一跳。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 对此响应最合适的状态码
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.30. 代理内部错误
- 名称:
- proxy_internal_error
- 描述:
- 中介遇到了与源无关的内部错误。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 500
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.31. 代理配置错误
- 名称:
- proxy_configuration_error
- 描述:
- 中介遇到了与其配置相关的错误。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 500
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.3.32. 检测到代理循环
- 名称:
- proxy_loop_detected
- 描述:
- 中介尝试将请求转发回自身，或通过其他方式检测到循环（例如，[RFC8586]）。
- 额外参数:
- 无
- 建议的 HTTP 状态码:
- 502
- 仅由中介生成响应:
- true
- 参考文献:
- RFC 9209
2.4. 定义新的代理错误类型
新的代理错误类型可以通过在“HTTP Proxy Error Types”注册表中注册来定义。
专家在评估请求时应考虑以下因素：
- 社区反馈
- 该值是否被定义得足够明确
- 优先使用通用类型而非供应商特定、应用特定或部署特定的值。如果社区无法就通用值达成一致，则类型名称应相应地更具体（例如，通过带有标识供应商、应用或部署的前缀）。
- 额外参数不应与已注册的 Proxy-Status 参数冲突。
注册请求应使用以下模板：
- 名称:
- [a name for the proxy error type that is of type Token]
- 描述:
- [a description of the conditions that generate the proxy error type]
- 额外参数:
- [zero or more optional parameters, along with their allowable Structured Type(s)]
- 建议的 HTTP 状态码:
- [the appropriate HTTP status code for this entry]
- 仅由中介生成响应:
- ['true' or 'false']
- 参考文献:
- [to a specification defining this error type; optional]
- 注释:
- [optional]
如果该代理错误类型可能出现在非中介生成的响应中——例如，在从正向连接流式传输响应时检测到错误，导致附加 Proxy-Status 尾部字段——则“仅由中介生成响应”字段应为 '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 节。
此外，以下条目已添加到“超文本传输协议 (HTTP) 字段名注册表”：
- 字段名:
- Proxy-Status
- 状态:
- permanent
- 规范文件:
- RFC 9209
- 备注:
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>.