Standards and sources

Proxy behaviour is defined across a surprisingly large set of documents, several of which have been obsoleted by newer ones that people still cite by the old number. This page is the index: what governs what, which document is current, and where the gaps are.

Core HTTP semantics#

The 2022 revision replaced the RFC 7230 to 7235 series. If you see a citation to RFC 7230 or RFC 2616, it is out of date, and in the case of RFC 2616 it has been obsolete since 2014.

RFC 9112 section 6.3, "Message Body Length", is the specific text behind HTTP request smuggling: when a message carries both Content-Length and Transfer-Encoding: chunked, the Transfer-Encoding overrides the Content-Length, and an intermediary that chooses to forward the message must first remove the received Content-Length field. Section 6.1 is the Transfer-Encoding field definition itself.

Forwarding and client identity#

That last row is the single most important fact on this page. The header the entire internet uses to identify clients has no normative definition, which is precisely why implementations disagree about ordering, duplication and trust.

Tunnelling and non-HTTP proxying#

Authentication#

TLS#

Addressing#

Vendor documentation#

Configuration claims are checked against the official documentation for the version named in the text.

• nginx documentation and the ngx_http_proxy_module, ngx_http_realip_module, ngx_http_upstream_module and ngx_stream_ssl_preread_module references
• HAProxy configuration manual, which is versioned per branch
• Envoy documentation and the xDS API reference
• Caddy documentation
• Traefik documentation, noting that v2 and v3 differ in matcher syntax
• curl manual and the changelog, which is unusually precise about when behaviour changed

Where the gaps are#

Three areas that this site covers have no normative specification at all, which is worth knowing before you argue about correct behaviour with a vendor:

1. X-Forwarded-For semantics. No RFC. Ordering, duplicate field handling and trust are conventions.
2. no_proxy matching. No specification of any kind. Every client implemented it independently, and they disagree, which is documented in the no_proxy environment variable and testable with the no_proxy tester.
3. PAC file semantics. The format originated as a Netscape document. Helper function behaviour, return string syntax support and error handling differ per browser. See PAC files and WPAD.

When there is no specification, "correct" means "matches the implementation you are actually running". That is why every page here version-qualifies its claims, and why the editorial standards require it.