New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for specifying the PathBase for all requests #5898

Open
davidfowl opened this Issue Jun 29, 2017 · 13 comments

Comments

Projects
None yet
8 participants
@davidfowl
Copy link
Member

davidfowl commented Jun 29, 2017

As a follow up from aspnet/Hosting#815, we want to allow specifying the path base as a host setting. Hosting should use this to call UsePathBase as the first middleware in the pipeline. IISIntegration does something similar with the APPL_PATH env variable : https://github.com/aspnet/IISIntegration/blob/51554566532237ef76cb105ec5b3f7a5050b9ba4/src/Microsoft.AspNetCore.Server.IISIntegration/WebHostBuilderIISExtensions.cs#L19.

@bklooste

This comment has been minimized.

Copy link

bklooste commented Jul 11, 2017

You want to be able to switch between WebListener ( or any host) and Kestrel which share the same startup before startup is loaded.. Having If (KestralLoaded) in startup is pretty damn ugly .. and makes testing a pain , i dont think there should be any Host ( including Kestrel) specific stuff in Startup .

@bklooste

This comment has been minimized.

Copy link

bklooste commented Jul 25, 2017

Using IStartupFilter is pretty ugly and having 2 methods for the 2 web hosts is pretty poor . As I mentioned before other systems may do a lot of work before startup eg console hosts , hosted by SF etc etc . Core and web listener supports this nicely but Kestrel does not. eg Hosting is a ASP.Net concept in startup I think the port/url hosting needs to be done before Startup .. Sure Startup should have access to this but it should be set before.

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Jul 26, 2017

I'm not sure what you're referring to but there will be a use path base on the IWebHostBuilder like the method suggests. I don't know what more you're asking for.

@jkotalik

This comment has been minimized.

Copy link
Contributor

jkotalik commented Aug 16, 2017

@davidfowl For testing this change, I believe I need to send a request to the application to verify that the HttpContext properly contains the PathBase.

Firstly, is there a better way to test this?

If this is correct, what type of test would this be? It seems to extend past the WebHosts tests because it requires that a request be sent to a server.

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Aug 16, 2017

@jkotalik Whats the issue with sending a request?

@Tratcher

This comment has been minimized.

Copy link
Member

Tratcher commented Aug 21, 2017

@ygoe

This comment has been minimized.

Copy link

ygoe commented Feb 3, 2018

Maybe it's a good idea to also make the use of proxy forwarding HTTP headers configurable for the hosting environment. Because these headers are provided by the hosting environment and could be different per host. The application shouldn't need to care about what headers the proxy provides.

My applications currently draw the application path base from an environment variable provided by my own hosting environment and put it into UsePathBase, and they also call UseForwardedHeaders because the hosting environment works that way.

But I can't influence third-party applications. They might stop working in some hosting environments.

@poke

This comment has been minimized.

Copy link
Contributor

poke commented Mar 24, 2018

I just stumbled on this issue again; what is the actual goal of this? To move the configuration of the path base into the WebHostBuilder, to ensure that it is always done at the very beginning of the middleware pipeline? And so that people can configure it through the host builder configuration (e.g. using environment variables, command line arguments, etc.?)

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Mar 24, 2018

@poke yes that was the intent

@poke

This comment has been minimized.

Copy link
Contributor

poke commented Mar 24, 2018

I see, I might have the chance to work on this then, seeing that this is not planned by someone else at this point.

Does the solution include any support for allowing to dynamically set the path base when sitting behaind a reverse proxy? In one of my applications, I currently use a custom X-Forwarded-Path HTTP header to dynamically configure the path base (along with the other X-Forwarded headers) to completely uncouple the configuration from the application, moving it into the reverse proxy configuration.

I don’t assume that we would want to move such a functionality into the webhost but keep it as custom middleware then, right (Just like the UseForwardedHeaders middleware)? In that case, we would have to make sure that the stuff in the webhost will not conflict here and that you could still overwrite the path base properly in user middleware.

@Tratcher

This comment has been minimized.

Copy link
Member

Tratcher commented Mar 24, 2018

X-Forwarded-Path would be an interesting add to UseForwardedHeaders, though it appears to be far less common.

The ask for Hosting is only for a static config based mapping for basic reverse proxy scenarios.

@Tratcher

This comment has been minimized.

Copy link
Member

Tratcher commented Mar 24, 2018

That said, I've seen some variants of this request in forums that UsePathBase does not cover. If the proxy trims or prepends the path then UsePathBase doesn't work, it relies on an unchanged path.

Examples:

A basic pass through:
Public Path: /foo/api/1
Proxy forwards: /foo/api/1
Fixup needed: UsePathBase(/foo), Path becomes: /api/1 and PathBase becomes: /foo

Variant 1: Proxy trims the path
Public Path: /foo/api/1
Proxy forwards /api/1
Fixup needed: Set PathBase to /foo, leave Path alone

Variant 2: Proxy prepends path
Public Path: /api/1
Proxy forwards /foo/api/1
Fixup needed: Remove /foo from Path, don't set PathBase

UsePathBase might need some overloads to handle these: Transfer, Set, Trim. I don't know how easily we could get those all into hosting config unless they were all separate parameters.

@damianh

This comment has been minimized.

Copy link

damianh commented Sep 13, 2018

Just got burned by this, specifically proxy trimming the path. Sorry I have nothing more valuable to add other than feedback from the wild.

@aspnet-hello aspnet-hello transferred this issue from aspnet/Hosting Dec 18, 2018

@aspnet-hello aspnet-hello added this to the Backlog milestone Dec 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment