ProxyHeadersMiddleware does not handle multiple values of X-Forwarded-Proto header

[pmeier]

While the X-Forwarded-* headers are not standardized, the RFC 7239 states the following about the Forwarded-* headers, which are supposed to be a replacement for the former (see #2237):

A proxy server that wants to add a new "Forwarded" header field value can either append it to the last existing "Forwarded" header field after a comma separator or add a new field at the end of the header block. (emphasis mine)

Meaning, the value cannot just be http or https, but also http,https.

Currently ProxyHeadersMiddleware just uses the value as is:

https://github.com/encode/uvicorn/blob/0efd3835da6dcc713f74aadf7b52779d0d1fa17d/uvicorn/middleware/proxy_headers.py#L55-L58

When building a URL from this, i.e. by FastAPI / starlette, we are effectively doing url = f"{scheme}://...".

When trying to process this further, starlette.datastructures.URL provides the replace method, which allows users to replace parts of the URL. Internally this relies on urllib.parse.urlsplit and the ._replace method of its result. However, in turn, this doesn't recognize the scheme and puts all the information into the path and ultimately losing the information:

>>> components = urlsplit("http,https://github.com/encode/uvicorn")
>>> components
SplitResult(scheme='', netloc='', path='http,https://github.com/encode/uvicorn', query='', fragment='')
>>> components._replace(path="/encode/httpx")
SplitResult(scheme='', netloc='', path='/encode/httpx', query='', fragment='')

Contrast this with the case of a valid scheme:

>>> components = urlsplit("https://github.com/encode/uvicorn")
>>> components
SplitResult(scheme='https', netloc='github.com', path='/encode/uvicorn', query='', fragment='')
>>> components._replace(path="/encode/httpx")
SplitResult(scheme='https', netloc='github.com', path='/encode/httpx', query='', fragment='')

We should process the header and only select one of the options for the scheme. For example, here is how Tornado is doing it:

if proto_header:
  # use only the last proto entry if there is more than one
  # TODO: support trusting multiple layers of proxied protocol
  proto_header = proto_header.split(",")[-1].strip()

I'm happy to provide a patch for this if we deem this an issue to be fixed.

[vanschelven]

#2468 does this actually, I misread; that PR doesn't touch X-Forwarded-Proto, only X-Forwarded-For

[vanschelven]

• previous discussion: scope["scheme"] is set to comma-separated list when such a value is present in the X-Forwarded-Proto header #2102
• previous (closed) PR: Add support for multiple values for the x-forwarded-proto header #2104

[ptrovatelli]

Hello,
I agree that multiple values in the same header should be supported.
But I have another issue: multiple headers of the same name are not supported either: if multiple X-Forwarded-Proto headers are defined (set by different reverse proxies), the earliest should be used, not the latest:

We have a uvicorn server running with 2 upstream reverse proxies:

• one reverse proxy when entering our infrastructure
• one reverse proxy when entering openshift (haproxy)

The first proxy does TLS offloading, thus changing protocol from https to http and setting the X-Forwarded-Proto / F-Forwarded-Port accordingly
The second proxy also sets X-Forwarded-Proto and F-Forwarded-Port but now the flow is already in http, so it's just adding new headers that are "not correct" if interpreted out of context (haproxy can be configured to add headers or modify existing headers)

This behavior is standard for this kind of headers : you can edit the previous header to add values, or you can add another header with the same name (for X-forwarded-for see https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For#syntax )

So when reaching uvicorn, the headers are:

[TLS offloading reverse proxy]
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "x-forwarded-for: <real_source_ip>"
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "x-forwarded-proto: https"
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "x-forwarded-port: 443"
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "forwarded: for=<real_source_ip>:443;proto=https"
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "x-forwarded-ssl: on"

[haproxy]
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "host: xxx"
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "x-forwarded-host: xxx"
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "x-forwarded-port: 80"
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "x-forwarded-proto: http"
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "forwarded: for=<intermediate_source_ip>;host=xxx;proto=http"
2026/04/30 11:39:48 [debug] 7#7: *204 http header: "x-forwarded-for: <intermediate_source_ip>"

It seems that in this case uvicorn uses the latest headers and believes that the original flow in http : when trying to connect to airflow through keycloak, when calling keycloak, airflow sets the redirect uri as http://myairflowapp instead of https://myairflowapp.
I was able to replicate this with both keycloak auth manager (alpha) and FAB auth manager.
I was able to fix the issue by adding an nginx side-car and re-define the X-Forwarded-Proto and X-Forwarded-Port headers just before reaching airflow container:

            location / {
                proxy_pass          http://127.0.0.1:8080;
                proxy_set_header    Host               $host;
                proxy_set_header    X-Forwarded-For    $proxy_add_x_forwarded_for;
                proxy_set_header    X-Forwarded-Host   $host;
                proxy_set_header    X-Forwarded-Server $host;
                # re-defining forwarded headers (uvicorn not looking at the oldest headers?)
                proxy_set_header    X-Forwarded-Port   443;
                proxy_set_header    X-Forwarded-Proto  https;
                proxy_set_header    Forwarded "";

[ptrovatelli]

Hello. My bad, I had anticipated this issue and I meant to configure HAProxy with "IfNone" mode but for some reason this was not deployed on this environment
It is a tricky part though, should be made apparent in the doc: if multiple reverse proxies are used, only the first one should define x-forwarded-* headers.
FYI the other solutions i've seen around is the definition of a "max number of trusted proxies" so that each proxy can add values and the application server will go up the chain only to a max number of header definition to avoid header poisoning by the end user