Visual RFC.
ALL RFCs / RFC 7239
Read the RFC ↗
RFC 7239 / FORWARDED HTTP REQUESTS

Apply trust and privacy decisions at the boundary

05

A client can write a Forwarded field too. Correct syntax cannot make an inherited chain trustworthy or make disclosure harmless.

DIAGRAMRead RFC section 8.1 ↗
RFC 7239 · § 8.1EXAMPLE
5 / 5
Apply trust and privacy decisions at the boundaryFive independent trust/privacy moments. A client supplies a plausible for192.0.2.10 claim that remains untrusted. A vetted edge chooses the MAY remove-all policy, discards that prefix and records its observed peer192.0.2.43. The backend considers only that local observation under an explicit proxy correctness and protected-link policy; this does not authenticate an earlier prefix. A separate privacy-request example follows SHOULD NOT and sends no Forwarded or other private data. A final reflection attempt stops before the client: request-only Forwarded should never be copied into responses, and TRACE reflection needs care. Obfuscation is not anonymity or encryption.A reported value is not proof of identityOriginClientreflect chain in a responseForwarded is request-onlyDo not copy the chain into responsesTRACE reflection needs special careInternal topology and client details may leak
05
Keep the chain out of responses.

This field is for requests, not responses. The depicted reflection path stops before the client; TRACE reflection requires special care as well.

Source for this drawing: RFC 7239 · Read RFC section 8.1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 9110 HTTP RFC 3986 URI syntax RFC 5952 IPv6 text

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Treat inherited claims as input, then apply explicit proxy and privacy policy.

  • Every node, including the client, can modify Forwarded. A trusted-proxy approach still cannot trust the prefix supplied before that proxy, and unsecured later links allow tampering.
  • for and by defaults SHOULD use obfuscated identifiers. Unless static assignment is necessary, they SHOULD be random per request; required persistent identifiers SHOULD NOT outlive client IP addresses.
  • If request fields specifically ask for privacy semantics, the proxy SHOULD NOT use Forwarded or otherwise pass private information onward. Obfuscation alone is not a guarantee of anonymity.
  • This request field should never be copied into responses. TRACE needs special care to avoid reflecting the chain in a response body.
DETAILS

Dropping inherited fields and generating a fresh local observation is one chosen MAY-remove policy, not a mandatory RFC algorithm. No cryptographic verifier, automatic allowlist, private user data, tracing system or proxy deployment is implemented here. Limited examples illustrate boundaries rather than prove privacy or security.

Read the RFC section ↗

All chapters in RFC 7239

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗