Closed RobSiklos closed 6 months ago
Just to rule it out, do you get the same problem if you also update KnownProxies
in the same way as you've done for KnownNetworks
?
@martincostello KnownProxies
takes single IP addresses, while KnownNetworks
takes ranges, so I can't update it in the same way. By adding "everything" to KnownNetworks
, it should rule out any possibility that the proxy isn't "known". Further, if the middleware was rejecting the proxy, the request.Scheme
wouldn't be updated from http
to https
, right?
I think if you call Clear()
on either, it'll allow everything too the same way as allowing the whole network.
@martincostello I don't think that's true, but it doesn't matter. Either way, it's not a factor because it's clear that the middleware in my sample IS processing the request, since it's updating the request.Scheme
property.
That's how I interpret this code:
If both are empty, then the networks shouldn't stop it processing the header or not.
Ok, you're correct. I've changed the sample to clear both KnownProxies
and KnownNetworks
, but the issue remains.
There is no bug here. X-Original-Proto
is not supposed to contain the value of X-Forwarded-Proto
. X-Original-Proto
is there to store the original value of HttpContext.Request.Scheme
(the original scheme on which the request was made) to avoid losing it as it will be overridden by the ForwardedHeadersMiddleware
middleware. If you need to access to the "forwarded" scheme, you can use HttpContext.Request.Scheme
after the middleware.
The same rule applies to:
X-Original-For
which contains the original value (before the middleware) of HttpContext.Connection.RemoteIpAddress
and HttpContext.Connection.RemotePort
X-Original-Host
which contains the original value of HttpContext.Request.Host
X-Original-Prefix
which contains the original value of HttpContext.Request.PathBase
Thanks @joegoldman2 - that makes a lot of sense. In that case, the documentation at https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-8.0 needs to be updated, because it states:
When processed, X-Forwarded-{For|Proto|Host} values are moved to X-Original-{For|Proto|Host}.
Docs issues can be filed in dotnet/AspNetCore.Docs.
Is there an existing issue for this?
Describe the bug
When using the ForwardedHeaders middleware, and the initial request uses HTTPS but the backend connection is HTTP, the
X-Original-Proto
header showshttp
instead ofhttps
.That is to say, when the connection to ASP.NET Core is HTTP, but the
X-Forwarded-Proto
header containshttps
, theX-Original-Proto
header showshttp
instead ofhttps
.Expected Behavior
The
X-Original-Proto
header showshttps
ifX-Forwarded-Proto
ishttps
Steps To Reproduce
Set up a new ASP.NET Core WebAPI project in Visual Studio 2022 with the following program also available at https://github.com/RobSiklos/ForwardedHeadersWebTest):
Now send a request via
http://
to the web app similar to the following:Exceptions (if any)
No response
.NET Version
8.0.100
Anything else?
Tried with .NET 6.0 and .NET 8.0 - same result.