Support the new "Forwarded" header (RFC 7239)

[cwe1ss]

There is now a standard for the most common X-Forwarded-* headers. It was introduced with RFC 7239: "Forwarded HTTP Extension".

Example: Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43

It would be great if this could be supported.

[Tratcher]

Yes, we've seen it. Are you aware of any proxies that actually set that new header?

[cwe1ss]

No - but I haven't looked either. I recently built a small ASP.NET gateway proxy for Azure Service Fabric and that's why I stumbled upon this RFC. I guess this definitely isn't high priority since there won't be anyone who's setting just this header for a looong time. It would just be good to support it someday since it is a standard and will eventually get more common.

[lantrix]

I have a scenario whereby we have a reverse proxy (internally) passing requests to backend api’s and web apps; and one of the api's is ASP.NET 5 and using the BasicMiddleware classes to handle the headers from the upstream proxies. The team had implemented the newer RFC so BasicMiddleware can't handle Forwarded headers from the RFC.

[asbjornu]

We're using Forwarded and plan to implement it in the proxies we use, such as NGINX. The header is becoming more mainstream and it would be good of Microsoft to advocate for its use over the (non-standard) X-Forwarded-* headers.

[damianh]

Would also like to have ability to extend the 'Forwared' header with a PathBase parameter as well as support for that with the current implementation i.e. X-Forwarded-PathBase

(somewhat) Related: https://github.com/aspnet/Hosting/issues/1120

[Tratcher]

@damianh do you expect PathBase to be different per request? That Hosting issue is about getting one value at startup.

[damianh]

Yes, I would certainly like to be able to do so on a per-request basis. This will allow two scenarios where generated URLs and paths (fully qualified, rooted, relative) would "just work":

1. Re-configuring the proxy to a new path base (e.g. http://proxy/foo/ -> http://backend/ to http://proxy/bar/ -> http://backend/ ) without having to reconfigure and restart the backend server.

2. Having one backend server responding on two separate paths (e.g. http://proxy/foo/ | http://proxy/bar/ -> http://backend/). Useful if "migrating" to a new route without breaking clients in situ.

[damianh]

@Tratcher This is what I use near top of my Configure(IApplicationBuilder app):

        var forwardedHeadersOptions = new ForwardedHeadersOptions
        {
            ForwardedHeaders = ForwardedHeaders.All
        };
        app.UseForwardedHeaders(forwardedHeadersOptions);
        app.Use((context, next) => {
            if (context.Request.Headers.TryGetValue("X-Forwarded-PathBase", out var pathBases))
            {
                context.Request.PathBase = pathBases.First();
            }
            return next();
        });

[colgreen]

"Are you aware of any proxies that actually set that new header?"

Arguably that point is somewhat circular, i.e. maybe if ASP.NET Core supported the 'Forwarded' header there would be more pressure on the reverse proxy implementations to support it. It is after all the only approach that actually has a formal specification (rfc7239).

[damianh]

Would also like to have ability to extend the 'Forwared' header with a PathBase parameter as well as support for that with the current implementation i.e. X-Forwarded-PathBase

Just to mention that I've shipped a package that supports this https://github.com/ProxyKit/HttpOverrides

[apeeters]

"Are you aware of any proxies that actually set that new header?"

Arguably that point is somewhat circular, i.e. maybe if ASP.NET Core supported the 'Forwarded' header there would be more pressure on the reverse proxy implementations to support it. It is after all the only approach that actually has a formal specification (rfc7239).

Indeed. If no one starts implementing the standard, it will never gain traction. Also: Spring has support for this Forwarded header since 2016...