Should HTTPSRedirectMiddleware take x-forwarded-proto: "https", into consideration?

[stdedos]

As an "always-worrying" user (and one trying to put multiple safeguards on stuff), I noticed that, even though "everything works" when I use HTTPSRedirectMiddleware locally, when I deploy the Docker image to a service that handles SSL termination (e.g. Azure Container Apps) - it seems that the HTTPSRedirectMiddleware drives the browser into a redirect loop.

The browser does go via HTTPS (and the service handles certificates etc.), but Starlette/FastAPI sees the plain HTTP traffic after TLS termination.

However, the headers correctly show X-Forwarded-Proto: https (among others).

Is this something that HTTPSRedirectMiddleware should take into account?

[cookesan]

I would not make HTTPSRedirectMiddleware trust X-Forwarded-Proto directly. That header is only meaningful after you have decided which proxy is trusted.

Starlette's middleware checks the ASGI scope["scheme"]. Behind TLS termination, the usual fix is to normalize the ASGI scope before HTTPSRedirectMiddleware runs, for example with Uvicorn proxy-header support configured for the correct trusted proxy IPs.

So the middleware order/config should be:

1. trusted proxy headers turn X-Forwarded-Proto: https into scope["scheme"] == "https"
2. HTTPSRedirectMiddleware sees the normalized scheme and does not redirect

If the app sees scope["scheme"] == "http" after TLS termination, Starlette is doing what it was told by the ASGI server. The proxy/header layer needs to be fixed first.

[MukundaKatta]

Classic TLS-terminating-proxy setup. The redirect loop comes from scope["scheme"] being http inside the container even though the client arrived over HTTPS. Fix is to normalize the ASGI scope before HTTPSRedirectMiddleware runs: uvicorn app:app --proxy-headers --forwarded-allow-ips '*' (or a specific CIDR), or wrap manually with ProxyHeadersMiddleware from uvicorn.middleware.proxy_headers. Folding x-forwarded-proto handling directly into HTTPSRedirectMiddleware would force trusted-proxy config into every header-aware middleware, fixing it once at the edge is cleaner.

[stdedos]

Aaah right!! --proxy-headers --forwarded-allow-ips '*' did the work!

For some reason, my forwarder was not in the 127.0.0.1 default - but I had assumed it was.

Thank you 😊