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

Separate the original host and protocol from the next hop

04

A reverse proxy may receive HTTPS for a public host and forward HTTP with a different Host value. Forwarded can report what that proxy received.

RFC 7239 · § 5.3EXAMPLE
4 / 4
Separate the original host and protocol from the next hopA chosen reverse-proxy example first receives HTTPS with Host shop.example:443. It records one element with for underscore req7, by underscore edge, quoted host shop.example:443 and proto https. Next it forwards over HTTP with Host internal.example, preserving its report of the earlier incoming host and scheme. A final stopped inference emphasizes proto https does not encrypt the current edge-to-origin link. TLS and local trust require separate checks; backend HTTP is chosen for illustration, not recommended deployment policy.Report what the edge receivedEdge proxyOrigininfer TLS from proto=httpsReported incoming proto=httpsCurrent link: HTTP in this exampleThe field does not add encryptionCheck connection protection and trust separately
04
Do not infer backend encryption.

proto=https does not mean the edge-to-origin connection is TLS protected. The reported incoming protocol and the current connection need separate checks.

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

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

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

host and proto report the incoming request, not protection of every connection.

  • host forwards the original Host value as received by the adding proxy, and after unescaping MUST conform to the referenced Host grammar.
  • proto reports the incoming protocol type. After unescaping it MUST use registered URI scheme syntax; typical values are http and https.
  • by identifies the proxy’s user-agent-facing interface; for identifies the node making the request to that proxy. Neither is automatically a backend address or authenticated user.
DETAILS

This fictional reverse proxy has explicitly enabled the selected fields. The backend Host rewrite and transport choices are examples, not requirements to use HTTP internally. The field cannot add TLS to an unprotected hop. Incoming metadata is usable only under an appropriate local trust policy.

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 ↗