Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Wrong Location when doing a redirect behind a Proxy. #540
When I'm proxying an application served by werkzeug, this application issues a redirect. In the code the redirect is asked for "/". But werkzeug will fill this URL wrongly: it'll use the X-FORWARDED-HOST as the real host. By doing this it'll do the reverse proxy's job of rewritting the url. And of course, as it is not his job, werkzeug doesn't do it right. It forgets the eventual subdirs.
The result is that I can't ProxyReverse any werkzeug application that should live in a subdirectory in my main frontend.
I have frontend apache host
So when hitting: http://www.frontend.com/abc
When the application issues a redirect, let me explicit the scenario to be clear:
So the header 'Location' is usually rewritten on-the-fly by the proxy before sending it the client. For instance: when it detects the pattern "http://internal-application.intranet" in the
But this doesn't work because werkzeug uses some information provided by the proxy to do some sort of a replacement of the
I don't think that werkzeug should do these changes, and it should rely on the proxy mecanism to do it's job.
Then werkzeug in file
So it calls
I've commented these two lines to test, used
If anything is wrong in my understanding of this, please tell me. If NOT using
Thanks for you comments.
The problem I have: I can't ProxyReverse any werkzeug application that'll use a redirect call behind a subdirectory of my main frontend.
That's a fairly big issue with werkzeug.
Basically, if werkzeug wouldn't do anything, it would work. For some reason, it tries to act clever, but it doesn't have enough information to do the right thing. The proxy is ready to do this job if only werkzeug doesn't mess the URL.
I think that get_host should be split in two:
Of course, if you have no X-Forwarded-Host in your header (you are not proxying werkzeug), then both version gives the same result.
The proxy is able to replace the "Location:" header, and it doesn't forget about the original subdirectory of the original URL:
But it's a simple string replace that is done. If the
For anyone else having trouble with this bug, you should be able to work around it with an extra ProxyPassReverse directive in the frontend apache config, something like this:
But there's an added complication that sometimes werkzeug's unwanted host-rewriting doesn't seem to happen (eg I don't see it with Flask's redirects to add a missing trailing slash).
referenced this issue
Oct 23, 2014
Are you certain this is a werkzeug problem and not a problem with whatever server you're using? I'm thinking this may be a server issue that is not exactly the result of anything on the werkzeug end.
I am experiencing a similar issue with my application sitting behind a reverse proxy. I believe our issues are one in the same in kind. The frontend server is running Microsoft IIS. For whatever reason, I believe it is IIS that is rewriting the location in the response header.
For example, I have in my Flask application the following:
This application sits behind a reverse proxy such that
If I access the application through the frontend server, I can't manage to redirect outside of
If access the route directly at
Regardless of what is interpreted as the host, a
The conclusion I've drawn is that the problem domain lies in the server handling the reverse proxy. In my specific case, it's the default rewrite behavior of the ARR/urlrewrite modules in IIS. Thusly, I don't believe there's any changes that can be made in the werkzeug code that will address this problem.