X-Forwarded-Proto
Behind a TLS-terminating proxy, the backend server has no way to determine whether the original connection was encrypted. The X-Forwarded-Proto unofficial request header communicates the original protocol (HTTP or HTTPS) the client used.
Usage
Load balancers and reverse proxies commonly terminate TLS connections and forward requests to backend servers over plain HTTP. When this happens, the backend has no way to determine whether the original client connection was encrypted. The X-Forwarded-Proto header communicates the original protocol so the backend reacts appropriately.
Backend applications use this value to enforce HTTPS Redirects, set secure cookie flags, and generate absolute URLs with the correct scheme. A Strict-Transport-Security policy relies on accurate protocol detection to avoid redirect loops when TLS termination occurs at a proxy.
The standardized replacement is the proto parameter of
the Forwarded header.
Values
The value is a single protocol identifier, typically http
or https. Some intermediaries send the value in lowercase,
others in uppercase. Backend applications comparing this
value perform case-insensitive matching.
X-Forwarded-Proto: https
X-Forwarded-Proto: http
Example
A load balancer terminates a TLS connection from a client and forwards the request over plain HTTP to the origin server. The load balancer includes the X-Forwarded-Proto header so the backend knows the client originally connected with HTTPS.
X-Forwarded-Proto: https
A backend application checking the protocol value determines
whether to issue an HTTPS
redirect. When the value is http,
the application responds with a 301 redirect to the
HTTPS version of the URL.
X-Forwarded-Proto: http
A combined set of forwarding headers arriving at a backend shows the full picture of the original client request.
X-Forwarded-For: 203.0.113.50
X-Forwarded-Host: www.example.re
X-Forwarded-Proto: https