:preserve_host semantics is upside-down #11
Comments
|
That makes sense to me. I'll take a look at it if you don't get to it first. |
|
I probably won't get around to it, I'm afraid, since I won't actually be needing a reverse-proxy in my app. |
|
Thanks for looking into it! |
eric1234
added a commit
to eric1234/rack-legacy
that referenced
this issue
Jan 20, 2014
The preserve_host option on rack-rewrite seems a bit off. I would assume it would mean it keeps the hostname requested. But instead it replaces it with the internal hostname (the host we proxy to). There is a ticket related to this (jaswope/rack-reverse-proxy#11). In addition, even if it pulled from the right host it also doesn't include the port. There is also already a ticket for this (jaswope/rack-reverse-proxy#17). To resolve this I simply avoiding using the preserve host option. This allows the original host to pass on through to PHP (it doesn't seem to need to be explicitly set, PHP already know it). Both of these option (wrong host and missing port) cause some PHP scripts, like Wordpress, who are trying to redirect to a canonical URL to get caught in an infinate loop. I am also now stripping out the index.php from the PATH_INFO before proxying off. The PHP webserver has it's own built-in method of looking for the index.php. So we add it for detecting the PHP handler should be called but then remove it to let PHP do things it's own way. This helps for script like Wordpress that try to direct to a canoncial URL. It prevent it from bouncing between index.php and the root directory. It may be slightly incorrect for cases where the user explicitly chose to pull up the index.php script. But in the real world I don't know where that would cause a problem and making this change solves a real world problem for Wordpress. Finally, I am passing on the HTTP_X_FORWARDED_FOR header. Although not standardized it is fairly widely and provide a way for the script to determine the IP address of the real browser since REMOTE_ADDR will be set to the proxy server.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
:preserve_host, when set to true, causes the Host header to be overridden, not to be preserved, unlike Apache's ProxyPreserveHost, which has the semantics you would expect.
In other words, given Rack app A reverse-proxying to B, with :preserve_host => false, it will send "Host: A", and with :preserve_host => true, it will send "Host: B".
It should be the other way around, i.e. false sends B and true sends A, so that the option means what it says, and to be consistent with Apache.
The default should probably be to not preserve the host, like Apache. (I'm not sure about the current default...)
The text was updated successfully, but these errors were encountered: