Forwarded HTTP Extension
Extracted elements (29)
Obfuscated port identifiers (obfport) use a leading underscore to distinguish them from numeric ports, enabling operators to retain traceability for debugging without revealing real port numbers or internal topology.
The "Forwarded" header was defined to standardize what X-Forwarded-For, X-Forwarded-By, and X-Forwarded-Proto do informally, providing interoperability and—crucially—combining all information in a single field so that data items can be correlated and attributed to the correct hop. The X-Forwarded-* class cannot provide such correlation guarantees.
The header is defined as optional and should be turned off by default, with each parameter configured individually, because the data it exposes is privacy- and security-sensitive. Proxies whose purpose is client anonymity are explicitly not required to implement it.
Proxies receiving X-Forwarded-For, X-Forwarded-By, or X-Forwarded-Proto headers are encouraged to convert them to the "Forwarded" field where sensible. However, when multiple X-Forwarded-* fields coexist, conversion may not be possible because the original ordering cannot be determined. Removing X-Forwarded-For may break parties that have not yet implemented "Forwarded".
The "Via" header field (RFC 7230 Section 5.7.1) has a similar purpose but only discloses information about the proxy itself, not the client. Because Via is already widely deployed and its format cannot be changed, "Forwarded" was defined separately. Information from the two headers cannot be correlated since some proxies update one but not the other.
A proxy MAY remove all "Forwarded" header fields from a request. It MUST, however, ensure that the correct header field is updated when multiple "Forwarded" header fields are present.
All extension parameters SHOULD be registered in the "HTTP Forwarded Parameter" registry. Extensions expected to have widespread deployment SHOULD also be standardized.
Each parameter MUST NOT occur more than once per field-value within a single forwarded-element.
The IPv6address in node identifiers SHOULD comply with RFC 5952 textual representation recommendations (e.g., lowercase, compression of zeros). An IPv6 address is always enclosed in square brackets.
The syntax for a "host" value, after potential quoted-string unescaping, MUST conform to the Host ABNF defined in RFC 7230 Section 5.4.
The syntax of a "proto" value, after potential quoted-string unescaping, MUST conform to the URI scheme name as defined in RFC 3986 Section 3.1 and registered with IANA per RFC 4395.
Unless static assignment is necessary, obfuscated identifiers SHOULD be randomly generated for each request. If they must persist across requests, they SHOULD NOT persist longer than client IP addresses.
When proxies choose to use the "by" parameter, its default configuration SHOULD contain an obfuscated identifier. An IP address MAY be used instead if the receiving server requires address-based functionality.
When proxies choose to use the "for" parameter, its default configuration SHOULD contain an obfuscated identifier. An IP address (and optionally port) MAY be used if the receiving server requires address-based functionality.
The client IP address carried in the "for" parameter can uniquely identify a client, reveal their operator, and estimate geographic location. If an HTTP request contains header fields specifically requesting privacy semantics, the proxy SHOULD NOT use the "Forwarded" field or otherwise pass private information such as IP addresses to the next hop.
The default configuration for both "by" and "for" parameters SHOULD contain obfuscated identifiers randomly generated per request. If persistent identifiers are required, their lifetimes SHOULD be limited and SHOULD NOT exceed the lifetime of client IP addresses. Even without unique client identifiers, the Forwarded header may enable fingerprinting by revealing the proxy chain.
The "by" parameter identifies the proxy's user-agent-facing interface (i.e., the interface on which the request arrived). Its syntax conforms to the node ABNF. It is primarily added by reverse proxies wishing to pass interface information to backend servers.
The "for" parameter discloses the client that initiated the request and any subsequent proxy identifiers in the chain. In a fully utilized chain, the first "for" value is the originating client, followed by intermediate proxies; the last proxy is not listed but is available as the transport-layer remote IP.
The "Forwarded" HTTP header field is an optional request-only header that allows proxy components to disclose information altered or lost during proxying, such as the originating client IP address, incoming interface IP, or protocol used. Each proxy in the chain may append a semicolon-separated set of parameter-identifier pairs. It is not to be used in HTTP responses.
The "host" parameter forwards the original value of the Host header field as received by the proxy. This allows origin servers behind reverse proxies that rewrite the Host header to recover the original host requested by the client.
The obfuscated identifier (obfnode) allows proxies to participate in tracing and debugging while concealing internal IP addresses. It MUST begin with a leading underscore "_" and consist only of ALPHA, DIGIT, ".", "_", and "-" characters.
The "proto" parameter indicates the application protocol used for the incoming request (e.g., "http" or "https"). Its value must conform to a URI scheme name registered with IANA, enabling origin servers behind TLS-offloading reverse proxies to generate correct URLs.
The "unknown" identifier is used when the identity of the preceding entity is not known but the proxy still wishes to signal that a forwarding occurred, for example when a proxy process lacks access to the incoming TCP socket.
IANA created the "HTTP Forwarded Parameters" registry with IETF Review as the registration procedure. Initial entries are "by", "for", "host", and "proto". New parameters and values MUST conform to the forwarded-pair ABNF, and their security and privacy implications must be thoroughly documented.
The "Forwarded" header field name was added to the IANA "Permanent Message Header Field Names" registry (RFC 3864) with applicable protocol "http" and status "standard".
The "Forwarded" header can reveal internal network structure behind NATs or proxies. Mitigations include using obfuscated identifiers, preventing internal nodes from updating the field, or having an egress proxy strip entries that reveal internal topology. The header MUST NOT be copied into responses, and TRACE requests should be disallowed where Forwarded is in use.
The "Forwarded" header cannot be relied upon to be correct; any node in the path, including the client, can modify or forge it. Whitelisting trusted proxies partially mitigates this, but IP addresses listed before the trusted proxy remain unverifiable, and network-level attackers can modify the field if connections between proxies are not secured.
Node identifiers follow the ABNF: `node = nodename [":" node-port]` where nodename is an IPv4address, bracketed IPv6address, "unknown", or obfnode (`"_" 1*(ALPHA / DIGIT / "." / "_" / "-")`). Port may be a numeric port (1–5 digits) or obfport with a leading underscore. IPv6 addresses and any nodename with a port MUST be quoted.
The Forwarded header value is defined as `Forwarded = 1#forwarded-element` where each `forwarded-element` is a semicolon-separated list of `forwarded-pair = token "=" value` items. Parameter names are case-insensitive; values may be tokens or quoted-strings. IPv6 addresses must be quoted since ":" and "[]" are not valid in token.