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

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

    While this clears up the problem for http requests, you will not be able to use https becuase 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 webserver 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 vaild, this is a clear case of wordpress not handling things appropriately.

    I’ve seen several other posts (and bug reports) about problems realted to this and they appear to have been shrugged off as being a configuration problem on the server side (and some of them really were). However, I believe the information / examples I’ve provided show cases where the servers are configured in a perfectly legitimate way (albeit not completely vanilla). Keep in mind that many clusters hosting solutions utilize an https proxy.

    I attempted to file this as a bug, but my login is not currently working on trac.www.remarpro.com, so I was not able to.

Viewing 2 replies - 1 through 2 (of 2 total)
  • We are having the same problem, although not with a secure connection. Because PHP and mod_perl won’t run together, we’re having to put WordPress on a non-standard port. Things work fine on the FIRST hit to our blog, but any subsequent hit shows the port number in the address bar (which is not OK). Did you ever figure anything out here?

    vbit

    (@vbit)

    I have exactly the same problem behind our reverse-proxy or just to create different development environments based on ports on the same server.
    We fixed a few things with more Apache rewriting rules and tricks but it’s getting complicated and we still have different problems.

    Ports and hosts for http and https should be considered as possible configuration variables if WordPress really have to rewrite url instead using bad assumptions!

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘HTTP_HOST redirect bug’ is closed to new replies.