-
Notifications
You must be signed in to change notification settings - Fork 134
Allow rewriting Response's Location header #76
Comments
Please check the pull request. Usage:
I still haven't understood your Unit Test yet so I will need your help on this. I have tested it with https://httpstat.us/301. |
It appears the upstream host is not aware of or using the x-forwarded headers. If it uses those headers, it would generate the correct absolute URL in the location header. Is this not the case? |
@datvm I've added a test #79 that ensures the location header is correct. If your upstream host is not generating the correct URLs then it is not configured to use Finally, if you really want or need to to do location header rewrites do it in your proxy code. Something like... app.RunProxy(async context =>
{
var response = await context
.ForwardTo("http://localhost:" + port + "/")
.AddXForwardedHeaders()
.Send();
if (response.Headers.Location != null)
{
response.Headers.Location = <rewrite here>;
}
return response;
})); ... which could be wrapped in an extension method. As such, I won't be accepting your proposed change. |
Scenario:
User enters https://www.example.com/foo (Server1)
Server1 proxies the request to https://localhost:123/foo (Server2)
Server2 responds with 202 or 301 with header
Location: https://localhost:123/bar
.Server1 forwards that header back, which when redirected, user is no longer accessing Server1.
Suggestion: add an option to allow rewriting Location header if it is present and is absolute Uri and the origin (scheme, host and port) is same as Server2's.
(I am working on it, going to create a pull request)
The text was updated successfully, but these errors were encountered: