Make WordPress Core

Opened 15 years ago

Closed 4 years ago

#8593 closed defect (bug) (wontfix)

HTTP_HOST being manipulated improperly for redirects

Reported by: revmj's profile revmj Owned by: markjaquith's profile markjaquith
Milestone: 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 13 years ago.
Patch by gynter, on IRC
8593.patch (556 bytes) - added by hakre 13 years ago.
casting to int added, patch still applies clean
8593.2.patch (4.5 KB) - added by hakre 13 years ago.
wp_requested_url()

Download all attachments as: .zip

Change History (18)

#1 @westi
15 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?

#2 @Denis-de-Bernardy
15 years ago

  • Milestone changed from 2.8 to Future Release

punting from lack of feedback

#3 @Denis-de-Bernardy
15 years ago

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

#4 @vladimir_kolesnikov
15 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.

#5 @Denis-de-Bernardy
15 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.

#6 @Denis-de-Bernardy
15 years ago

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

#7 @azaozz
14 years ago

  • Milestone changed from 2.9 to Future Release

No patch.

#8 @chiether
14 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?

@scribu
13 years ago

Patch by gynter, on IRC

#9 @scribu
13 years ago

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

@hakre
13 years ago

casting to int added, patch still applies clean

#10 @hakre
13 years ago

+1 Thanks for reporting this. Related: #16858

Last edited 13 years ago by hakre (previous) (diff)

#11 @hakre
13 years ago

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

@hakre
13 years ago

wp_requested_url()

#12 @hakre
13 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

#13 @chriscct7
9 years 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.

#14 @chriscct7
8 years ago

  • Milestone changed from Future Release to Awaiting Review

#15 @markjaquith
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.