WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 7 months ago

#8593 new defect (bug)

HTTP_HOST being manipulated improperly for redirects

Reported by: revmj Owned by: markjaquith
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Canonical Keywords: dev-feedback needs-refresh
Focuses: Cc:

Description

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.

Attachments (3)

pastie-1361767.diff (401 bytes) - added by scribu 4 years ago.
Patch by gynter, on IRC
8593.patch (556 bytes) - added by hakre 4 years ago.
casting to int added, patch still applies clean
8593.2.patch (4.5 KB) - added by hakre 4 years ago.
wp_requested_url()

Download all attachments as: .zip

Change History (16)

comment:1 @westi6 years ago

  • Keywords reporter-feedback added; HTTP_HOST redirect loop removed

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?

comment:2 @Denis-de-Bernardy6 years ago

  • Milestone changed from 2.8 to Future Release

punting from lack of feedback

comment:3 @Denis-de-Bernardy6 years ago

  • Component changed from General to Canonical
  • Owner changed from anonymous to markjaquith

comment:4 @vladimir_kolesnikov6 years ago

  • Cc vladimir@… added

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.

comment:5 @Denis-de-Bernardy6 years ago

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.

comment:6 @Denis-de-Bernardy6 years ago

  • Keywords needs-patch added
  • Milestone changed from Future Release to 2.9

comment:7 @azaozz5 years ago

  • Milestone changed from 2.9 to Future Release

No patch.

comment:8 @chiether5 years ago

  • Cc chiether added

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

./wp-includes/canonical.php:344

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

...affect this ticket?

@scribu4 years ago

Patch by gynter, on IRC

comment:9 @scribu4 years ago

  • Keywords has-patch added; reporter-feedback needs-patch removed

@hakre4 years ago

casting to int added, patch still applies clean

comment:10 @hakre4 years ago

+1 Thanks for reporting this.

Version 0, edited 4 years ago by hakre (next)

comment:11 @hakre4 years ago

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

@hakre4 years ago

wp_requested_url()

comment:12 @hakre4 years ago

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

comment:13 @chriscct77 months ago

  • Keywords dev-feedback needs-refresh added; has-patch removed

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.

Note: See TracTickets for help on using tickets.