HTTP_HOST being manipulated improperly for redirects

[revmj]

When redirecting a hit to the proper URL, WordPress makes some bad assumptions. Specifically, during redirects, any port information provided by the client is dropped. If I go to ​http://example.com:80/, I get redirected to ​http://example.com/. If I go to ​https://example.com:443/, I get redirected to ​https://example.com/.

Thus far, no problem has occurred because we are on on server that uses default ports. However, lets say my web server is running http on 8080 and https on 8443. Now when I go to ​http://example.com:8080/ and get redirected to ​http://example.com/, it fails. As a workaround, you can change the following settings:
WordPress address: ​http://example.com:8080/
Blog address: ​http://example.com:8080/

While this clears up the problem for http requests, you will not be able to use https becuse and attempt to go to ​https://example.com:8443/ now redirects to ​https://example.com:8080/ and it fails because the server does not speak ssl on 8080.

Additionally, when you have an https proxy in front of your web server such as pound (with http on port 80 and https on port 8443), you run into another problem caused by this same bug. In this situation if you attempt to go to ​https://example.com/, the proxy server accepts the request and then on the back end makes a none ssl connection to apache. Good so far, but in order to not make any assumptions, the proxy server tells apache that the request was for '​https://example.com:443/' and apache sets HTTP_HOST (very appropriately) to example.com:443. WordPress sees this request and redirects it to '​https://example.com/' by responding to the web browser with a 'Location:' header. Thus the browser sends another request for '​https://example.com/' and starts the whole process over again resulting in an infinite redirect.

As specifying a port is completely valid, this is a clear case of WordPress not handling things appropriately.

[westi]

WordPress respects the ports when it is configured correctly.

What have you configured for:

• WordPress address (URL)
• Blog address (URL)

And how are you expecting to be able to access the site?

[Denis-de-Bernardy]

punting from lack of feedback

[vladimir_kolesnikov]

I was able to reproduce this behavior only on mathopd web server. The bug (in mathopd) was that it did not specify the port number in $_SERVERHTTP_HOST? (other servers do).

If anybody is interested, I can submit the patch.

[Denis-de-Bernardy]

not sure what the proper solution is, though. if someone sticks http onto 5555 and https on 5556 for some weird reason, then we really have no means to sort this one out unless we keep the port set by the user.

[azaozz]

No patch.

[chiether]

Im looking some "Redirect Loop" tickets however set duplicate.

Some browser has been infinity redirect; because send "Host: example.com:443" when access to "​https://example.com/"
I think more better $requested_url should be confirmed HttpHeader and with DefaultPort(80,443).

target(in v3.0):

./wp-includes/canonical.php:45

• make $requested_url by $_SERVERHTTPS?, $_SERVERHTTP_HOST? and $_SERVERREQUEST_URI?.

./wp-includes/canonical.php:344

• conditional branch to return false. ( $redirect_url == $requested_url )

...affect this ticket?

[scribu]

Patch by gynter, on IRC

[hakre]

casting to int added, patch still applies clean

[hakre]

+1 Thanks for reporting this. Related: #16858

[hakre]

Both patches do wrong, I'm currently looking into this.

[hakre]

wp_requested_url()

[hakre]

I've done some testing with this. 'HTTP_PORT' is not set as far as I can see on multiple setups and 'HTTP_HOST' conains the port number in case it's not the standard port of the protocol.

So actually HTTP_HOST is to look into.

Patch introduces a new function called wp_requested_url() which is of general use to retrieve the requested URI or URL.

It does so by dealing with default http(s) ports as well so removing them in case they are not needed.

Additionally, it's possible to to switch the requested URL into a SSL or non SSL variant by making use of an optional parameter.

It might even make sense to make it filter-able so that specific server/cache/proxy setups can deal with the requested URL if they need to do so.

Related: #16884

[chriscct7]

Most of the places the most recent patch changes are no longer in WordPress core. Issue needs to be re-evaluated and if decision is made to keep the issue open, patch will need to be refreshed.

[markjaquith]

Much like with #19337, this should be handled by server config or middleware.