[wp-hackers] When HTTP_HOST does not point to the blog

Oliver Hohlfeld oliver at ohohlfeld.com
Tue Jun 24 18:29:57 GMT 2008


Hi,

I'm using WordPress on an Apache Vhost which -- for some reason I didn't
figure out so far - does not set the correct HTTP_HOST as specified in the
ServerName setting. Thus, requests to $_SERVER['HTTP_HOST'] will not be
directed to the requested blog.

I noticed this issue when updating WordPress to version 2.3 which caused
an infinite redirection loop due to canonical URLs. When examining the
problem I noticed that some other users experienced the same problem and
this is the main motivation for my post. I'm not sure whether this is an
issue that should be really considered, as this is probably caused by a
misconfiguration of my Apache HTTP server. But maybe it is worth a pointer.

The initial problem with the redirect loop was caused by an HTTP_HOST
environmental setting that does not correspond to the true host name of the
blog. Further analysis showed that also some other parts are affected by
this; the cron functionality can not be accessed and the self link in ATOM
feeds points to a wrong host. I ignored some places where HTTP_HOST is used
in the admin interface so far.

To fix these issues, I mostly changed the host to the one specified in the
configuration:

   $site_url = get_option( ’siteurl’ );
   if (strlen($site_url) > 0) {
     $parts = parse_url( $site_url );
     $requested_url .= $parts['host'];
   } else {
     $requested_url .= $_SERVER['HTTP_HOST'];
   }

I briefly described these changes in my blog post, in hope of some other
people experiencing the same problem might find that useful:
http://blog.ohohlfeld.com/2008/06/infinite-301-redirect-loop-in-wordpress-due-to-canonical-urls-fixed/

Regarding the cron, requests are directed to the correct host, as specified
in the configuration ( $argyle = @ fsockopen( $parts['host'], .... ), but
by supplying a wrong HTTP Host attribute. When using name based virtual
hosts, several servers will listen on a single IPs. Requests are distinguished
by the "Host: " attribute supplied in the HTTP header. As
$_SERVER['HTTP_HOST'] != $parts['host'] in my case, requests will be directed
to a wrong virtual host causing a 404 - file not found (wp-cron.php does not
exist on this particular vhost).
In general, I'm not sure whether it makes sense to establish a connection to
$parts['host'] but then issue an request for HTTP_HOST.

However, these changes fixed the host related issues for me, but I'm not
sure whether this is useful in general...
Would it be useful to add a getBlogHost() procedure whose code might look like
the above mentioned block?

--Oliver


More information about the wp-hackers mailing list