When HTTP_HOST does not point to the blog

[Oliver Hohlfeld-3]

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
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Kimmo Suominen-4]

Isn't $_SERVER['HTTP_HOST'] basically data supplied by the browser?
Shouldn't WordPress use $_SERVER['SERVER_NAME'] instead, which is
data provided by the web server?

Since I run my site on a dedicated IP (for https) I sometimes get
requested without $_SERVER['HTTP_HOST'] set at all.  I always thought
that was because there simply was no "Host:" header in the request.

Best regards,
+ Kimmo
--
<A HREF="http://kimmo.suominen.com/">Kimmo Suominen</A>


On Tue, Jun 24, 2008 at 08:29:57PM +0200, Oliver Hohlfeld wrote:

> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Oliver Hohlfeld-3]

Hi,

> Isn't $_SERVER['HTTP_HOST'] basically data supplied by the browser?
> Shouldn't WordPress use $_SERVER['SERVER_NAME'] instead, which is
> data provided by the web server?

Right. I forgot to mention something. Our web servers are not directly
reachable from the outside world and are accessed though an Apache
server running mod_proxy. The proxy will direct the requests to the
right machines and will thus change the HTTP_HOST in the internal
request (from the proxy to the web server)...
This causes the host mismatch. The correct host is supplied in
X-Forwarded-Host, but there is probably a way to solve this Apache
related issue.

Basically, I'm aware that this is a very special issue and I only
posted it as I noticed some other people had similar problems with
canonical URLs. Of course, they may be caused by something different.
Thus, I'm not sure if this issue really needs to be considered, but
I thought it's maybe worth a pointer.

--Oliver

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Andy Skelton]

On Tue, Jun 24, 2008 at 1:29 PM, Oliver Hohlfeld <oliver@...> wrote:
> 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.

$_SERVER['HTTP_*'] are populated with HTTP request headers. So if I
include this header:

X-Andy: awesome

you will find:

$_SERVER['HTTP_X_ANDY'] == 'awesome'

WordPress and countless themes and plugins rely on HTTP_HOST. You must
figure out why it is not being set to the value of the HTTP Host
header.

Andy
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Andy Skelton]

On Tue, Jun 24, 2008 at 2:52 PM, Oliver Hohlfeld <oliver@...> wrote:
> Right. I forgot to mention something. Our web servers are not directly
> reachable from the outside world and are accessed though an Apache
> server running mod_proxy. The proxy will direct the requests to the
> right machines and will thus change the HTTP_HOST in the internal
> request (from the proxy to the web server)...
> This causes the host mismatch. The correct host is supplied in
> X-Forwarded-Host, but there is probably a way to solve this Apache
> related issue.

Okay, now this is familiar territory! Since it is an issue with your
configuration, you should put the fix in your customized wp-config.php
file rather than in WordPress. Something like this:

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

Of course, HTTP headers should be treated as suspiciously as any
user-supplied input. Take precautions against clients spoofing headers
even if it just means verifying that your proxy won't allow that
header to pass. Maybe you should also ensure that the request came
through the proxy by checking REMOTE_ADDRESS and X_FORWARDED_FOR for
sanity, but here you have the basic solution.

Cheers,
Andy
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Oliver Hohlfeld-3]

Hi,

> Okay, now this is familiar territory! Since it is an issue with your
> configuration, you should put the fix in your customized wp-config.php
> file rather than in WordPress. Something like this:
>
> if ( isset( $_SERVER['HTTP_X_FORWARDED_HOST'] ) )
>     $_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];

This is an elegant work-around. Thanks for the hint! Sometimes one
doesn't see the wood for the trees. ;-)

--Oliver
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers