Hateful new year, everybody.
I installed WordPress behind an Apache reverse proxy. At least I tried
to, but because this means WordPress is running internally on a
different port number from that of its public URL, it gets itself in a
twist trying to construct links to itself, and the web-based installer
ends up in an infinite redirect loop.
Fortunately I'd encountered this before, I knew to grub around in the
database, removing the port number from the siteurl and home entries in
the options table. This fixes WordPress's idea of what its own URL is,
and makes the site and admin interface work.
At least, mostly work. Curiously, a few links in the admin interface
were still broken, linking to URLs with the internal-only port number in
them. Delving into the code I found the culprit to be this line:
$current_url = ( is_ssl() ? 'https://' : 'http://' )
. $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
$_SERVER['HTTP_HOST'] is the hostname complete with the port number.
But, why on earth is WordPress hatefully deriving its current URL from
HTTP headers when it already has a config variable with the URL in it?
And why is it, hatefully, only doing this for _some_ links?
Moreover, why does it even need to do this at all? The $current_url
variable is used for generating a link URL to put in the HTML source. I
fixed it by replacing the above with:
$current_url = $_SERVER['REQUEST_URI'];
That makes the HTML emit a path-only URL, which web browsers have been
handily resolving into absolute URLs since the early 90s. So not only is
WordPress getting this wrong by ignoring its own config (but only in
some places), it didn't need to bother -- it's hatefully doing a
completely unnecessary task, then hatefully getting it wrong, in a
hatefully inconsistent manner.
But that wasn't enough. The above change only fixed one class of broken
links. ack-ing the source showed HTTP_HOST to be used more than a
handful of times. It's hatefully doing this with duplicated code. That
looked tedious to fix.
So I read the Apache mod_proxy docs and found the ProxyPreserveHost
directive. This makes Apache lie to the inner web serving running
WordPress about its Host: header. It seems to fix things. But it's
documented as:
This option should normally be turned Off. It is mostly useful in
special configurations like proxied mass name-based virtual hosting,
where the original Host header needs to be evaluated by the backend
server.
So I'm left with an uneasy feeling about it. What on earth does "should"
mean there? That turning it on is fragile and may have broken things?
(If so, what?) That it would be unwise of me to default to using this
whenever setting up an internal proxied site? (If so, why?) Or simply
that the docs were written by a prescriptivist Apache developer with
particular ideas on how to set things up and looks snootily at anybody
who chooses to do it differently?
I know this is Hates Software, not Hates Documentation, but providing a
feature then telling users they "should" not "normally" use it is
tantalizing. (And hateful.)
Bah.
Smylers
--
http://twitter.com/Smylers2
