Running WordPress behind Apache mod_proxy

WordPress 2.3 (the blog software I’m using) introduced the concept of canonical URLs, which caused a problem on my host after upgrading. To sum it up, there are many possible ways to access an article or a page in WordPress and the concept of canonical URLs will redirect pages to the permanent link specified in the settings. After upgrading to WordPress >2.3, my blog was no longer reachable, due to an infinite redirection loop:

$ wget blog.ohohlfeld.com
–2008-06-24 18:43:50–  http://blog.ohohlfeld.com/
Resolving blog.ohohlfeld.com… 83.236.4.78
Connecting to blog.ohohlfeld.com|83.236.4.78|:80… connected.
HTTP request sent, awaiting response… 301 Moved Permanently
Location: http://blog.ohohlfeld.com/ [following]
–2008-06-24 18:43:51–  http://blog.ohohlfeld.com/
Reusing existing connection to blog.ohohlfeld.com:80.
HTTP request sent, awaiting response… 301 Moved Permanently
Location: http://blog.ohohlfeld.com/ [following]
–2008-06-24 18:43:51–  http://blog.ohohlfeld.com/
Reusing existing connection to blog.ohohlfeld.com:80.
HTTP request sent, awaiting response… 301 Moved Permanently
Location: http://blog.ohohlfeld.com/ [following]

(….) repeated infinitely

This problem is caused by an incorrectly set host attribute within the HTTP header due to mod_proxy. When using mod_proxy, an Apache server running the proxy will redirect requests to the corresponding web servers. In this internal HTTP request, the Apache proxy sets the Host: to the name of the internal host and thus HTTP_HOST is containing some different host name to what is set by the requesting browser. The original host name is populated in X-Forwarded-Host by mod_proxy. Thus, this is a special issue caused by this non-common Apache configuration.

As WordPress relies on a correctly set HTTP_HOST in some situation (redirects by the URL canonicalization, calling wp-cron, self-tag in ATOM feeds, …), it should be overwritten when a valid X-Forwarded-Host attribute is set in the HTTP header, as Andy pointed out. Basically (without further sanity checks), this can be accomplished by adding the following code to wp-config.php:

if ( isset( $_SERVER['HTTP_X_FORWARDED_HOST'] ) )
 $_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];

Moreover, when plugins — such as Wassup — rely on aquiring the IP address of the calling user, the REMOTE_ADDRESS can be overwritten, as this will always point to the Apache running mod_proxy. I solved this by adding the following code to wp-config.php:

$_SERVER['REMOTE_ADDR'] = zen_get_ip_address();

The zen_get_ip_address(); procedure will return the correct IP address.

However, as already mentioned, these changes are not nessesarry when some of the discussed HTTP header attribute are not modified by an in-between proxy, which should be the normal case!