Internet Engineering Task Force (IETF) A. Petersson
Request for Comments: 7239 M. Nilsson
Category: Standards Track Opera Software
ISSN: 2070-1721 June 2014
Internet Engineering Task Force (IETF) A. Petersson
Request for Comments: 7239 M. Nilsson
Category: Standards Track Opera Software
ISSN: 2070-1721 June 2014
Forwarded HTTP Extension
转发的HTTP扩展
Abstract
摘要
This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.
本文档定义了一个HTTP扩展标头字段，该字段允许代理组件披露代理过程中丢失的信息，例如，请求的原始IP地址或面向用户代理的界面上代理的IP地址。在代理组件的路径中，这使得可以对其进行排列，以便每个后续组件都可以访问（例如）代理HTTP请求链中使用的所有IP地址。
This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.
本文档还指定了代理管理员匿名化请求来源的指导原则。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7239.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7239.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Notational Conventions ..........................................4
3. Syntax Notations ................................................4
4. Forwarded HTTP Header Field .....................................4
5. Parameters ......................................................6
5.1. Forwarded By ...............................................6
5.2. Forwarded For ..............................................6
5.3. Forwarded Host .............................................7
5.4. Forwarded Proto ............................................7
5.5. Extensions .................................................7
6. Node Identifiers ................................................8
6.1. IPv4 and IPv6 Identifiers ..................................9
6.2. The "unknown" Identifier ...................................9
6.3. Obfuscated Identifier ......................................9
7. Implementation Considerations ..................................10
7.1. HTTP Lists ................................................10
7.2. Header Field Preservation .................................10
7.3. Relation to Via ...........................................10
7.4. Transition ................................................11
7.5. Example Usage .............................................11
8. Security Considerations ........................................12
8.1. Header Validity and Integrity .............................12
8.2. Information Leak ..........................................12
8.3. Privacy Considerations ....................................12
9. IANA Considerations ............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
Appendix A. Acknowledgments .......................................16
1. Introduction ....................................................3
2. Notational Conventions ..........................................4
3. Syntax Notations ................................................4
4. Forwarded HTTP Header Field .....................................4
5. Parameters ......................................................6
5.1. Forwarded By ...............................................6
5.2. Forwarded For ..............................................6
5.3. Forwarded Host .............................................7
5.4. Forwarded Proto ............................................7
5.5. Extensions .................................................7
6. Node Identifiers ................................................8
6.1. IPv4 and IPv6 Identifiers ..................................9
6.2. The "unknown" Identifier ...................................9
6.3. Obfuscated Identifier ......................................9
7. Implementation Considerations ..................................10
7.1. HTTP Lists ................................................10
7.2. Header Field Preservation .................................10
7.3. Relation to Via ...........................................10
7.4. Transition ................................................11
7.5. Example Usage .............................................11
8. Security Considerations ........................................12
8.1. Header Validity and Integrity .............................12
8.2. Information Leak ..........................................12
8.3. Privacy Considerations ....................................12
9. IANA Considerations ............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
Appendix A. Acknowledgments .......................................16
In today's HTTP landscape, there are a multitude of different applications that act as proxies for the user agents. In many cases, these proxies exists without the action or knowledge of the end-user. These cases occur, for example, when the proxy exists as a part of the infrastructure within the organization running the web server. Such proxies may be used for features such as load balancing or crypto offload. Another example is when the proxy is used within the same organization as the user, and the proxy is used to cache resources. However, these proxies make the requests appear as if they originated from the proxy's IP address, and they may change other information in the original request. This represents a loss of information from the original request.
在今天的HTTP环境中，有许多不同的应用程序充当用户代理的代理。在许多情况下，这些代理在最终用户不采取行动或不知情的情况下存在。例如，当代理作为运行web服务器的组织内的基础结构的一部分存在时，就会发生这些情况。此类代理可用于负载平衡或加密卸载等功能。另一个例子是，代理与用户在同一个组织中使用，并且代理用于缓存资源。但是，这些代理使请求看起来好像来自代理的IP地址，并且它们可能会更改原始请求中的其他信息。这表示原始请求中的信息丢失。
This loss of information can cause problems for a web server that has a specific use for the clients' IP addresses that will not be met by using the address of the proxy or other information changed by the proxy. The main uses of this information are for diagnostics, access control, and abuse management. Diagnostic functions can include event logging, troubleshooting, and statistics gathering, and the information collected is usually only stored for short periods of time and only gathered in response to a particular problem or a complaint from the client. Access control can be operated by configuring a list of client IP addresses from which access is permitted, but this approach will not work if a proxy is used, unless the proxy is trusted and is, itself, configured with a list of allowed client addresses for the server. Cases of abuse require identification of the abuser and this uses many of the same features identified for diagnostics.
这种信息丢失可能会导致特定使用客户端IP地址的web服务器出现问题，而使用代理的地址或代理更改的其他信息将无法满足这些问题。此信息主要用于诊断、访问控制和滥用管理。诊断功能可以包括事件记录、故障排除和统计数据收集，收集的信息通常只存储很短的时间，并且仅在响应特定问题或客户投诉时收集。可以通过配置允许访问的客户端IP地址列表来操作访问控制，但如果使用代理，则此方法将不起作用，除非该代理是受信任的，并且其本身配置了服务器的允许客户端地址列表。虐待案件需要识别施虐者，这使用了许多相同的特征来进行诊断。
Most of the time that a proxy is used, this loss of information is not the primary purpose, or even a desired effect, of using the proxy. Thus, to restore the desired functionality when a proxy is in use, a way of disclosing the original information at the HTTP level is needed. Clearly, however, when the purpose of using a proxy is to provide client anonymity, the proxy will not use the feature defined in this document.
在使用代理的大多数情况下，这种信息丢失不是使用代理的主要目的，甚至不是期望的效果。因此，要在使用代理时恢复所需的功能，需要一种在HTTP级别公开原始信息的方法。但是，显然，当使用代理的目的是提供客户匿名性时，代理不会使用本文档中定义的功能。
It should be noted that the use of a reverse proxy also hides information. Again, where the loss of information is not a deliberate function of the use of the reverse proxy, it can be desirable to find a way to encode the information within the HTTP messages so that the consumer can see it.
应该注意的是，使用反向代理也会隐藏信息。同样，如果信息丢失不是使用反向代理故意造成的，则可能需要找到一种方法在HTTP消息中对信息进行编码，以便消费者可以看到它。
A common way to disclose this information is by using the non-standard header fields such as X-Forwarded-For, X-Forwarded-By, and X-Forwarded-Proto. There are many benefits to using a standardized
公开此信息的常用方法是使用非标准头字段，如X-Forwarded-For、X-Forwarded-by和X-Forwarded-Proto。使用标准化的
approach to commonly desired protocol function: not least is interoperability between implementations. This document standardizes a header field called "Forwarded" and provides the syntax and semantics for disclosing such information. "Forwarded" also combines all the information within one single header field, making it possible to correlate that information. With the header field format described in this document, it is possible to know what information belongs together, as long as the proxies are trusted. Such conclusions are not possible to make with the X-Forwarded class of header fields. The header field defined in this document is optional such that implementations of proxies that are intended to provide privacy are not required to operate or implement the header field.
实现普遍需要的协议功能的方法：不仅仅是实现之间的互操作性。本文档标准化了名为“转发”的标题字段，并提供了披露此类信息的语法和语义。“转发”还将所有信息合并到一个标题字段中，从而可以关联该信息。使用本文档中描述的标题字段格式，只要代理是可信的，就可以知道哪些信息属于一起。对于X-Forwarded类的头字段，不可能得出这样的结论。本文档中定义的标题字段是可选的，因此操作或实现标题字段不需要使用旨在提供隐私的代理实现。
Note that similar issues to those described for proxies also arise with use of NATs. This is discussed further in [RFC6269].
请注意，使用NAT时也会出现与代理类似的问题。这将在[RFC6269]中进一步讨论。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with the list rule extension defined in Section 7 of [RFC7230].
本规范使用[RFC5234]的增广巴科斯诺尔形式（ABNF）表示法以及[RFC7230]第7节中定义的列表规则扩展。
The "Forwarded" HTTP header field is an OPTIONAL header field that, when used, contains a list of parameter-identifier pairs that disclose information that is altered or lost when a proxy is involved in the path of the request. Due to the sensitive nature of the data passed in this header field (see Sections 8.2 and 8.3), this header field should be turned off by default. Further, each parameter should be configured individually. "Forwarded" is only for use in HTTP requests and is not to be used in HTTP responses. This applies to forwarding proxies, as well as reverse proxies. Information passed in this header field can be, for example, the source IP address of the request, the IP address of the incoming interface on the proxy, or whether HTTP or HTTPS was used. If the request is passing through several proxies, each proxy can add a set of parameters; it can also remove previously added "Forwarded" header fields.
“转发的”HTTP头字段是一个可选的头字段，在使用时，它包含一个参数标识符对列表，这些参数标识符对公开了当代理涉及请求路径时更改或丢失的信息。由于在该标题字段中传递的数据的敏感性（参见第8.2节和第8.3节），默认情况下应关闭该标题字段。此外，应单独配置每个参数。“转发”仅用于HTTP请求，不用于HTTP响应。这适用于转发代理和反向代理。此标头字段中传递的信息可以是，例如，请求的源IP地址、代理上传入接口的IP地址，或者是否使用了HTTP或HTTPS。如果请求通过多个代理，每个代理可以添加一组参数；它还可以删除以前添加的“转发”标题字段。
The top-level list is represented as a list of HTTP header field-values as defined in Section 3.2 of [RFC7230]. The first element in this list holds information added by the first proxy that implements and uses this header field, and each subsequent element holds information added by each subsequent proxy. Because this header field is optional, any proxy in the chain may choose not to update this header field. Each field-value is a semicolon-separated list; this sublist consists of parameter-identifier pairs. Parameter-identifier pairs are grouped together by an equals sign. Each parameter MUST NOT occur more than once per field-value. The parameter names are case-insensitive. The header field value can be defined in ABNF syntax as:
顶级列表表示为[RFC7230]第3.2节中定义的HTTP头字段值列表。此列表中的第一个元素保存由实现和使用此标头字段的第一个代理添加的信息，每个后续元素保存由每个后续代理添加的信息。由于此标头字段是可选的，因此链中的任何代理都可以选择不更新此标头字段。每个字段值是一个分号分隔的列表；此子列表由参数标识符对组成。参数标识符对通过等号分组在一起。每个字段值的每个参数不得出现一次以上。参数名称不区分大小写。标题字段值可以在ABNF语法中定义为：
Forwarded = 1#forwarded-element
转发=1#转发元素
forwarded-element = [ forwarded-pair ] *( ";" [ forwarded-pair ] )
转发元素=[转发对]*（“；”[转发对]）
forwarded-pair = token "=" value
value = token / quoted-string
forwarded-pair = token "=" value
value = token / quoted-string
token = <Defined in [RFC7230], Section 3.2.6>
quoted-string = <Defined in [RFC7230], Section 3.2.6>
token = <Defined in [RFC7230], Section 3.2.6>
quoted-string = <Defined in [RFC7230], Section 3.2.6>
Examples:
示例：
Forwarded: for="_gazonk"
Forwarded: For="[2001:db8:cafe::17]:4711"
Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43
Forwarded: for=192.0.2.43, for=198.51.100.17
Forwarded: for="_gazonk"
Forwarded: For="[2001:db8:cafe::17]:4711"
Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43
Forwarded: for=192.0.2.43, for=198.51.100.17
Note that as ":" and "[]" are not valid characters in "token", IPv6 addresses are written as "quoted-string".
请注意，由于“：”和“[]”不是“令牌”中的有效字符，IPv6地址被写为“带引号的字符串”。
A proxy server that wants to add a new "Forwarded" header field value can either append it to the last existing "Forwarded" header field after a comma separator or add a new field at the end of the header block. A proxy MAY remove all "Forwarded" header fields from a request. It MUST, however, ensure that the correct header field is updated in case of multiple "Forwarded" header fields.
要添加新的“转发”标头字段值的代理服务器可以将其附加到逗号分隔符后的上一个现有“转发”标头字段，或在标头块的末尾添加新字段。代理可以从请求中删除所有“转发”头字段。但是，它必须确保在出现多个“转发”标头字段的情况下更新正确的标头字段。
This document specifies a number of parameters and valid values for each of them:
本文档为每个参数指定了许多参数和有效值：
o "by" identifies the user-agent facing interface of the proxy.
o “by”标识代理的面向用户代理的界面。
o "for" identifies the node making the request to the proxy.
o “for”标识向代理发出请求的节点。
o "host" is the host request header field as received by the proxy.
o “主机”是代理收到的主机请求头字段。
o "proto" indicates what protocol was used to make the request.
o “proto”表示发出请求所使用的协议。
The "by" parameter is used to disclose the interface where the request came in to the proxy server. When proxies choose to use the "by" parameter, its default configuration SHOULD contain an obfuscated identifier as described in Section 6.3. If the server receiving proxied requests requires some address-based functionality, this parameter MAY instead contain an IP address (and, potentially, a port number). A third option is the "unknown" identifier described in Section 6.2.
“by”参数用于显示请求进入代理服务器的接口。当代理选择使用“by”参数时，其默认配置应包含第6.3节所述的模糊标识符。如果接收代理请求的服务器需要一些基于地址的功能，则此参数可能包含IP地址（以及可能包含的端口号）。第三个选项是第6.2节中描述的“未知”标识符。
The syntax of a "by" value, after potential quoted-string unescaping, conforms to the "node" ABNF described in Section 6.
“by”值的语法，在潜在的引用字符串取消后，符合第6节中描述的“node”ABNF。
This is primarily added by reverse proxies that wish to forward this information to the backend server. It can also be interesting in a multihomed environment to signal to backend servers from which the request came.
这主要是由希望将此信息转发到后端服务器的反向代理添加的。在多主机环境中，向请求来自的后端服务器发送信号也很有趣。
The "for" parameter is used to disclose information about the client that initiated the request and subsequent proxies in a chain of proxies. When proxies choose to use the "for" parameter, its default configuration SHOULD contain an obfuscated identifier as described in Section 6.3. If the server receiving proxied requests requires some address-based functionality, this parameter MAY instead contain an IP address (and, potentially, a port number). A third option is the "unknown" identifier described in Section 6.2.
“for”参数用于披露有关发起请求的客户端以及代理链中后续代理的信息。当代理选择使用“for”参数时，其默认配置应包含第6.3节所述的模糊标识符。如果接收代理请求的服务器需要一些基于地址的功能，则此参数可能包含IP地址（以及可能包含的端口号）。第三个选项是第6.2节中描述的“未知”标识符。
The syntax of a "for" value, after potential quoted-string unescaping, conforms to the "node" ABNF described in Section 6.
“for”值的语法，在潜在的带引号的字符串取消后，符合第6节中描述的“node”ABNF。
In a chain of proxy servers where this is fully utilized, the first "for" parameter will disclose the client where the request was first made, followed by any subsequent proxy identifiers. The last proxy in the chain is not part of the list of "for" parameters. The last proxy's IP address, and optionally a port number, are, however, readily available as the remote IP address at the transport layer. It can, however, be more relevant to read information about the last proxy from preceding "Forwarded" header field's "by" parameter, if present.
在充分利用这一点的代理服务器链中，第一个“for”参数将显示首次发出请求的客户机，然后是任何后续代理标识符。链中的最后一个代理不在“for”参数列表中。然而，最后一个代理的IP地址和可选的端口号在传输层作为远程IP地址随时可用。但是，从前面的“Forwarded”标头字段的“by”参数（如果存在）中读取关于最后一个代理的信息可能更相关。
The "host" parameter is used to forward the original value of the "Host" header field. This can be used, for example, by the origin server if a reverse proxy is rewriting the "Host" header field to some internal host name.
“主机”参数用于转发“主机”标题字段的原始值。例如，如果反向代理正在将“主机”头字段重写为某个内部主机名，则源服务器可以使用此选项。
The syntax for a "host" value, after potential quoted-string unescaping, MUST conform to the Host ABNF described in Section 5.4 of [RFC7230].
“主机”值的语法，在潜在的带引号的字符串取消后，必须符合[RFC7230]第5.4节中描述的主机ABNF。
The "proto" parameter has the value of the used protocol type. The syntax of a "proto" value, after potential quoted-string unescaping, MUST conform to the URI scheme name as defined in Section 3.1 in [RFC3986] and registered with IANA according to [RFC4395]. Typical values are "http" or "https".
“proto”参数具有所用协议类型的值。“proto”值的语法在潜在的带引号的字符串取消后，必须符合[RFC3986]第3.1节中定义的URI方案名称，并根据[RFC4395]向IANA注册。典型值为“http”或“https”。
For example, in an environment where a reverse proxy is also used as a crypto offloader, this allows the origin server to rewrite URLs in a document to match the type of connection as the user agent requested, even though all connections to the origin server are unencrypted HTTP.
例如，在反向代理还用作加密卸载程序的环境中，这允许源服务器重写文档中的URL，以匹配用户代理请求的连接类型，即使到源服务器的所有连接都是未加密的HTTP。
Extensions allow for additional parameters and values. Extensions can be particularly useful in reverse proxy environments. All extension parameters SHOULD be registered in the "HTTP Forwarded Parameter" registry. If certain extensions are expected to have widespread deployment, they SHOULD also be standardized. This is further discussed in Section 9.
扩展允许附加参数和值。扩展在反向代理环境中特别有用。所有扩展参数都应在“HTTP转发参数”注册表中注册。如果预期某些扩展将广泛部署，那么它们也应该标准化。这将在第9节中进一步讨论。
The node identifier is one of the following:
节点标识符是以下之一：
o The client's IP address, with an optional port number
o 客户端的IP地址，带有可选端口号
o A token indicating that the IP address of the client is not known to the proxy server
o 表示代理服务器不知道客户端IP地址的令牌
o A generated token, allowing for tracing and debugging, while allowing the internal structure or sensitive information to be hidden
o 生成的令牌，允许跟踪和调试，同时允许隐藏内部结构或敏感信息
The node identifier is defined by the ABNF syntax as:
ABNF语法将节点标识符定义为：
node = nodename [ ":" node-port ]
nodename = IPv4address / "[" IPv6address "]" /
"unknown" / obfnode
node = nodename [ ":" node-port ]
nodename = IPv4address / "[" IPv6address "]" /
"unknown" / obfnode
IPv4address = <Defined in [RFC3986], Section 3.2.2>
IPv6address = <Defined in [RFC3986], Section 3.2.2>
obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-")
IPv4address = <Defined in [RFC3986], Section 3.2.2>
IPv6address = <Defined in [RFC3986], Section 3.2.2>
obfnode = "_" 1*( ALPHA / DIGIT / "." / "_" / "-")
node-port = port / obfport
port = 1*5DIGIT
obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-")
node-port = port / obfport
port = 1*5DIGIT
obfport = "_" 1*(ALPHA / DIGIT / "." / "_" / "-")
DIGIT = <Defined in [RFC5234], Section 3.4>
ALPHA = <Defined in [RFC5234], Section B.1>
DIGIT = <Defined in [RFC5234], Section 3.4>
ALPHA = <Defined in [RFC5234], Section B.1>
Each of the identifiers may optionally have the port identifier, for example, allowing the identification of the endpoint in a NATed environment. The "node-port" can be identified either by its port number or by a generated token obfuscating the real port number. An obfuscated port may be used in situations where the possessor of the proxy wants the ability to trace requests -- for example, in debug purposes -- but does not want to reveal internal information.
每个标识符可以可选地具有端口标识符，例如，允许在特定环境中识别端点。“节点端口”可以通过其端口号或生成的混淆真实端口号的令牌来识别。如果代理的所有者希望能够跟踪请求（例如，出于调试目的），但不希望透露内部信息，则可以使用模糊端口。
Note that the ABNF above also allows port numbers to be appended to the "unknown" identifier. Interpretation of such notation is, however, left to the possessor of a proxy adding such a value to the header field. To distinguish an "obfport" from a port, the "obfport" MUST have a leading underscore. Further, it MUST also consist of only "ALPHA", "DIGIT", and the characters ".", "_", and "-".
请注意，上面的ABNF还允许将端口号附加到“未知”标识符。但是，将此类符号的解释权留给代理的拥有者将此类值添加到标题字段。要区分“obfport”和端口，“obfport”必须有一个前导下划线。此外，它还必须仅由“ALPHA”、“DIGIT”和字符“.”、“u”和“-”组成。
It is important to note that an IPv6 address and any nodename with node-port specified MUST be quoted, since ":" is not an allowed character in "token".
需要注意的是，必须引用IPv6地址和指定了节点端口的任何节点名，因为“：”不是“令牌”中允许的字符。
Examples:
示例：
"192.0.2.43:47011"
"[2001:db8:cafe::17]:47011"
"192.0.2.43:47011"
"[2001:db8:cafe::17]:47011"
The ABNF rules for "IPv6address" and "IPv4address" are defined in [RFC3986]. The "IPv6address" SHOULD comply with textual representation recommendations [RFC5952] (for example, lowercase, compression of zeros).
[RFC3986]中定义了“IPV6地址”和“IPV4地址”的ABNF规则。“IPv6address”应符合文本表示建议[RFC5952]（例如，小写、零压缩）。
Note that the IP address may be one from the internal nets, as defined in [RFC1918] and [RFC4193]. Also, note that an IPv6 address is always enclosed in square brackets.
请注意，IP地址可能来自[RFC1918]和[RFC4193]中定义的内部网络。另外，请注意，IPv6地址始终用方括号括起来。
The "unknown" identifier is used when the identity of the preceding entity is not known, but the proxy server still wants to signal that a forwarding of the request was made. One example would be a proxy server process generating an outgoing request without direct access to the incoming request TCP socket.
当前面实体的标识未知，但代理服务器仍希望发出转发请求的信号时，将使用“未知”标识符。一个示例是代理服务器进程生成传出请求，而不直接访问传入请求TCP套接字。
A generated identifier may be used where there is a wish to keep the internal IP addresses secret, while still allowing the "Forwarded" header field to be used for tracing and debugging. This can also be useful if the proxy uses some sort of interface labels and there is a desire to pass them rather than an IP address. Unless static assignment of identifiers is necessary for the server's use of the identifiers, obfuscated identifiers SHOULD be randomly generated for each request. If the server requires that identifiers persist across requests, they SHOULD NOT persist longer than client IP addresses. To distinguish the obfuscated identifier from other identifiers, it MUST have a leading underscore "_". Furthermore, it MUST also consist of only "ALPHA", "DIGIT", and the characters ".", "_", and "-". Example:
在希望对内部IP地址保密的情况下，可以使用生成的标识符，同时仍然允许使用“转发”头字段进行跟踪和调试。如果代理使用某种接口标签，并且希望传递它们而不是IP地址，那么这也很有用。除非服务器使用标识符需要静态分配标识符，否则应为每个请求随机生成模糊标识符。如果服务器要求标识符在请求之间持续存在，则标识符的持续时间不应超过客户端IP地址。要将混淆的标识符与其他标识符区分开来，它必须有一个前导下划线“\u1”。此外，它还必须仅由“ALPHA”、“DIGIT”和“.”、“u”和“-”字符组成。例子：
Forwarded: for=_hidden, for=_SEVKISEK
Forwarded: for=_hidden, for=_SEVKISEK
Note that an HTTP list allows white spaces to occur between the identifiers, and the list may be split over multiple header fields. As an example, the header field
请注意，HTTP列表允许在标识符之间出现空格，并且该列表可以拆分为多个头字段。例如，标题字段
Forwarded: for=192.0.2.43,for="[2001:db8:cafe::17]",for=unknown
Forwarded: for=192.0.2.43,for="[2001:db8:cafe::17]",for=unknown
is equivalent to the header field
相当于标题字段
Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]", for=unknown
Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]", for=unknown
which is equivalent to the header fields
这相当于标题字段
Forwarded: for=192.0.2.43
Forwarded: for="[2001:db8:cafe::17]", for=unknown
Forwarded: for=192.0.2.43
Forwarded: for="[2001:db8:cafe::17]", for=unknown
There are some cases when this header field should be kept and some cases where it should not be kept. A directly forwarded request should preserve and possibly extend it. If a single incoming request causes the proxy to make multiple outbound requests, special care must be taken to decide whether or not the header field should be preserved. In many cases, the header field should be preserved, but if the outbound request is not a direct consequence of the incoming request, the header field should not be preserved. Consider also the case when a proxy has detected a content mismatch in a 304 response and is following the instructions in [RFC7232], Section 4.1 to repeat the request unconditionally, in which case the new request is still basically a direct consequence of the origin request, and the header field should probably be kept.
有些情况下应保留此标题字段，有些情况下不应保留此标题字段。直接转发的请求应该保留并可能扩展它。如果单个传入请求导致代理发出多个出站请求，则必须特别注意决定是否应保留标头字段。在许多情况下，应该保留标头字段，但如果出站请求不是传入请求的直接结果，则不应该保留标头字段。还考虑代理在304响应中检测到内容不匹配的情况，并且遵循中国[RCF722]第4.1节中的指令，无条件地重复请求，在这种情况下，新请求基本上是源请求的直接结果，并且应该保持标题字段。
The "Via" header field (see [RFC7230], Section 5.7.1) is a header field with a similar use case as this header field. The "Via" header field, however, only provides information about the proxy itself, and thereby leaves out the information about the client connecting to the proxy server. The "Forwarded" header field, on the other hand, has relaying information from the client-facing side of the proxy server as its main purpose. As "Via" is already widely deployed, its format cannot be changed to address the problems that "Forwarded" addresses.
“Via”标题字段（参见[RFC7230]，第5.7.1节）是一个标题字段，其用例与此标题字段类似。然而，“Via”头字段仅提供有关代理本身的信息，因此省略了有关连接到代理服务器的客户端的信息。另一方面，“Forwarded”头字段的主要用途是从代理服务器面向客户端的一侧中继信息。由于“Via”已经广泛部署，其格式无法更改以解决“转发”地址的问题。
Note that it is not possible to combine information from this header field with the information from the Via header field. Some proxies will not update the "Forwarded" header field, some proxies will not update the Via header field, and some proxies will update both.
请注意，无法将来自此标头字段的信息与来自Via标头字段的信息组合在一起。有些代理不会更新“转发”标题字段，有些代理不会更新Via标题字段，有些代理会同时更新这两个字段。
If a proxy gets incoming requests with X-Forwarded-* header fields present, it is encouraged to convert these into the header field described in this document, if it can be done in a sensible way. If the request only contains one type -- for example, X-Forwarded-For -- this can be translated to "Forwarded", by prepending each element with "for=". Note that IPv6 addresses may not be quoted in X-Forwarded-For and may not be enclosed by square brackets, but they are quoted and enclosed in square brackets in "Forwarded".
如果代理收到存在X-Forwarded-*头字段的传入请求，建议将这些字段转换为本文档中描述的头字段（如果可以以合理的方式完成）。如果请求仅包含一种类型（例如X-Forwarded-for），则可以通过在每个元素前面加上“for=”将其转换为“Forwarded”。请注意，IPv6地址可能不会在X-Forwarded-For中引用，也可能不会用方括号括起来，但它们会在“Forwarded”中引用并用方括号括起来。
X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17
X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17
becomes:
变成：
Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]"
Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]"
However, special care must be taken if, for example, both X-Forwarded-For and X-Forwarded-By exist. In such cases, it may not be possible to do a conversion, since it is not possible to know in which order the already existing fields were added. Also, note that removing the X-Forwarded-For header field may cause issues for parties that have not yet implemented support for this new header field.
但是，如果存在X-Forwarded-for和X-Forwarded-By，则必须特别小心。在这种情况下，可能无法进行转换，因为无法知道已存在字段的添加顺序。另外，请注意，删除X-Forwarded-For标头字段可能会导致尚未实现对该新标头字段支持的各方出现问题。
A request from a client with IP address 192.0.2.43 passes through a proxy with IP address 198.51.100.17, then through another proxy with IP address 203.0.113.60 before reaching an origin server. This could, for example, be an office client behind a corporate malware filter talking to a origin server through a reverse proxy.
来自IP地址为192.0.2.43的客户端的请求通过IP地址为198.51.100.17的代理，然后通过IP地址为203.0.113.60的另一个代理，然后到达源服务器。例如，这可能是公司恶意软件过滤器背后的office客户端通过反向代理与源服务器进行通信。
o The HTTP request between the client and the first proxy has no "Forwarded" header field.
o 客户端和第一个代理之间的HTTP请求没有“转发”头字段。
o The HTTP request between the first and second proxy has a "Forwarded: for=192.0.2.43" header field.
o 第一个和第二个代理之间的HTTP请求有一个“Forwarded:for=192.0.2.43”头字段。
o The HTTP request between the second proxy and the origin server has a "Forwarded: for=192.0.2.43, for=198.51.100.17;by=203.0.113.60;proto=http;host=example.com" header field.
o 第二个代理和源服务器之间的HTTP请求有一个“转发：for=192.0.2.43，for=198.51.100.17；by=203.0.113.60；proto=HTTP；host=example.com”头字段。
Note that, at some points in a connection chain, the information might not be updated in the "Forwarded" header field, either because of lack of support of this HTTP extension or because of a policy decision not to disclose information about this network component.
请注意，在连接链中的某些点上，“转发”标头字段中的信息可能不会更新，这可能是因为缺少对此HTTP扩展的支持，也可能是因为策略决定不披露有关此网络组件的信息。
The "Forwarded" HTTP header field cannot be relied upon to be correct, as it may be modified, whether mistakenly or for malicious reasons, by every node on the way to the server, including the client making the request.
“转发的”HTTP头字段不能被认为是正确的，因为它可能被发送到服务器的每个节点（包括发出请求的客户端）错误地或恶意地修改。
One approach to ensure that the "Forwarded" HTTP header field is correct is to verify the correctness of proxies and to whitelist them as trusted. This approach has at least two weaknesses. First, the chain of IP addresses listed before the request came to the proxy cannot be trusted. Second, unless the communication between proxies and the endpoint is secured, the data can be modified by an attacker with access to the network.
确保“转发”HTTP头字段正确的一种方法是验证代理的正确性，并将其列为受信任的白名单。这种方法至少有两个弱点。首先，在请求到达代理之前列出的IP地址链是不可信的。其次，除非代理和端点之间的通信是安全的，否则具有网络访问权限的攻击者可以修改数据。
The "Forwarded" HTTP header field can reveal internal structures of the network setup behind the NAT or proxy setup, which may be undesired. This can be addressed either by using obfuscated elements, by preventing the internal nodes from updating the HTTP header field, or by having an egress proxy remove entries that reveal internal network information.
“转发”HTTP头字段可以显示NAT或代理设置背后的网络设置的内部结构，这可能是不需要的。这可以通过使用模糊元素、防止内部节点更新HTTP头字段或让出口代理删除显示内部网络信息的条目来解决。
This header field should never be copied into response messages by origin servers or intermediaries, as it can reveal the whole proxy chain to the client. As a side effect, special care must be taken in hosting environments not to allow the TRACE request where the "Forwarded" field is used, as it would appear in the body of the response message.
源服务器或中介不应将此标头字段复制到响应消息中，因为它可能会向客户端显示整个代理链。作为一个副作用，在托管环境中必须特别小心，不要允许使用“转发”字段的跟踪请求，因为它会出现在响应消息的正文中。
In recent years, there have been growing concerns about privacy. There is a trade-off between ensuring privacy for users versus disclosing information that is useful, for example, for debugging, statistics, and generating location-dependent content. The "Forwarded" HTTP header field, by design, exposes information that some users consider privacy sensitive, in order to allow for such uses. For any proxy, if the HTTP request contains header fields that
近年来，人们越来越关注隐私问题。在确保用户隐私与披露有用信息（例如，用于调试、统计和生成位置相关内容）之间存在权衡。通过设计，“转发”HTTP报头字段公开一些用户认为隐私敏感的信息，以便允许这样的使用。对于任何代理，如果HTTP请求包含
specifically request privacy semantics, the proxy SHOULD NOT use the "Forwarded" header field, nor in any other manner pass private information, such as IP addresses, on to the next hop.
特别是请求隐私语义，代理不应使用“转发”头字段，也不应以任何其他方式将私有信息（如IP地址）传递到下一跳。
The client's IP address, that may be forwarded in the "for" parameter of this header field, is considered to be privacy sensitive by many people, as the IP address may be able to uniquely identify a client, what operator the user is using, and possibly a rough estimation of where the user is geographically located.
许多人认为可以在该报头字段的“for”参数中转发的客户端的IP地址是隐私敏感的，因为该IP地址可以唯一地识别客户端、用户正在使用的运营商以及可能的用户地理位置的粗略估计。
Proxies using this extension will preserve the information of a direct connection. This has an end-user privacy impact regardless of whether the end-user or deployer knows or expects that this is the case.
使用此扩展的代理将保留直接连接的信息。无论最终用户或部署人员是否知道或预期会发生这种情况，这都会对最终用户隐私产生影响。
Implementers and deployers of such proxies need to consider whether, and how, deploying this extension affects user privacy.
这些代理的实现者和部署者需要考虑部署该扩展是否以及如何影响用户隐私。
The default configuration for both the "by" and "for" parameters SHOULD contain obfuscated identifiers. These identifiers SHOULD be randomly generated per request. If identifiers that persist across requests are required, their lifetimes SHOULD be limited and they SHOULD NOT persist longer than client IP addresses. When generating obfuscated identifiers, care must be taken not to include potentially sensitive information in them.
“by”和“for”参数的默认配置应包含模糊标识符。每个请求都应随机生成这些标识符。如果需要跨请求持久化的标识符，则应限制它们的生存时间，并且它们的持久化时间不应超过客户端IP地址。生成模糊标识符时，必须注意不要在其中包含潜在的敏感信息。
Note that users' IP addresses may already be forwarded by proxies using the header field X-Forwarded-For, which is widely used. It should also be noted that if the user were doing the connection directly without passing the proxy, the client's IP address would be sent to the web server. Users that do not actively choose an anonymizing proxy cannot rely on having their IP address shielded. These users who want to minimize the risk of being tracked must also note that there are other ways information may leak, for example, by browser header field fingerprinting. The Forwarded header field itself, even when used without a uniquely identifying client identifier, may make fingerprinting more feasible by revealing the chain of proxies traversed by the client's request.
请注意，用户的IP地址可能已经由代理使用广泛使用的标头字段X-forwarded-For转发。还应注意，如果用户直接进行连接而不通过代理，则客户端的IP地址将发送到web服务器。不主动选择匿名代理的用户不能依靠屏蔽其IP地址。这些希望将被跟踪的风险降至最低的用户还必须注意，还有其他可能导致信息泄漏的方式，例如，通过浏览器标题字段指纹识别。转发的报头字段本身，即使在没有唯一标识的客户机标识符的情况下使用，也可以通过揭示客户机请求所经过的代理链，使指纹识别更加可行。
This document specifies the HTTP header field listed below, which has been added to the "Permanent Message Header Field Names" registry defined in [RFC3864].
本文档指定了下面列出的HTTP标头字段，该字段已添加到[RFC3864]中定义的“永久消息标头字段名称”注册表中。
Header field: Forwarded Applicable protocol: http Status: standard Author/Change controller: IETF (iesg@ietf.org) Internet Engineering Task Force Specification document(s): this specification (Section 4) Related information: None
标题字段：转发适用协议：http状态：标准作者/变更控制器：IETF(iesg@ietf.org)互联网工程任务组规范文件：本规范（第4节）相关信息：无
The "Forwarded" header field contains parameters for which IANA has created and now maintains a new registry entitled "HTTP Forwarded Parameters". Initial registrations are given below. For future assignments, the registration procedure is IETF Review [RFC5226]. The security and privacy implications of all new parameters should be thoroughly documented. New parameters and their values MUST conform with the forwarded-pair as defined in ABNF in Section 4. Further, a short description should be provided in the registration.
“转发”标题字段包含IANA为其创建的参数，现在维护一个名为“HTTP转发参数”的新注册表。初步登记如下。对于未来的任务，注册程序为IETF审查[RFC5226]。应彻底记录所有新参数的安全和隐私影响。新参数及其值必须符合第4节ABNF中定义的转发对。此外，应在注册中提供简短说明。
+-------------+---------------------------------------+-------------+
| Parameter | Description | Reference |
| name | | |
+-------------+---------------------------------------+-------------+
| by | IP address of incoming interface of a | Section 5.1 |
| | proxy | |
| for | IP address of client making a request | Section 5.2 |
| | through a proxy | |
| host | Host header field of the incoming | Section 5.3 |
| | request | |
| proto | Application protocol used for | Section 5.4 |
| | incoming request | |
+-------------+---------------------------------------+-------------+
+-------------+---------------------------------------+-------------+
| Parameter | Description | Reference |
| name | | |
+-------------+---------------------------------------+-------------+
| by | IP address of incoming interface of a | Section 5.1 |
| | proxy | |
| for | IP address of client making a request | Section 5.2 |
| | through a proxy | |
| host | Host header field of the incoming | Section 5.3 |
| | request | |
| proto | Application protocol used for | Section 5.4 |
| | incoming request | |
+-------------+---------------------------------------+-------------+
Table 1: Initial Assignments
表1：初步分配
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年6月。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：条件请求”，RFC 7232，2014年6月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月。
Thanks to Per Cederqvist, Alissa Cooper, Adrian Farrel, Stephen Farrell, Ned Freed, Per Hedbor, Amos Jeffries, Poul-Henning Kamp, Murray S. Kucherawy, Barry Leiba, Salvatore Loreto, Alexey Melnikov, S. Moonesamy, Susan Nichols, Mark Nottingham, Julian Reschke, John Sullivan, Willy Tarreau, and Dan Wing for their feedback.
感谢佩尔·塞德克维斯特、艾莉莎·库珀、阿德里安·法雷尔、斯蒂芬·法雷尔、内德·弗里德、佩尔·海德堡、阿莫斯·杰弗里斯、波尔·亨宁·坎普、默里·库切拉维、巴里·莱巴、萨尔瓦托·洛雷托、阿列克谢·梅尔尼科夫、S·穆内萨米、苏珊·尼科尔斯、马克·诺丁汉、朱利安·雷什克、约翰·沙利文、威利·塔罗和丹·温的反馈。
Authors' Addresses
作者地址
Andreas Petersson Opera Software
安德烈亚斯彼得森歌剧院软件
EMail: andreas@sbin.se
EMail: andreas@sbin.se
Martin Nilsson Opera Software S:t Larsgatan 12 Linkoping SE-582 24
Martin Nilsson Opera Software S:t Larsgatan 12 Linkoping SE-582 24
EMail: nilsson@opera.com
EMail: nilsson@opera.com