[development] Loading configuration using 'SERVER_NAME' as opposed to 'HTTP_HOST'
steinwrites4u at yahoo.com
Tue Mar 17 00:35:26 UTC 2009
please please i need to unsubscribe to drupal
help me their protocols do not work
Thanks David stein
--- On Mon, 3/16/09, Adam Cooper <adam.j.cooper at gmail.com> wrote:
From: Adam Cooper <adam.j.cooper at gmail.com>
Subject: Re: [development] Loading configuration using 'SERVER_NAME' as opposed to 'HTTP_HOST'
To: development at drupal.org
Date: Monday, March 16, 2009, 2:40 PM
> This is more a support question and should be on the support list but see
Granted this is could be a support issue, but I had intended to (mostly) gauge
the validity of a patch to core. Is that not a development question?
> My question back to you is why isn't HTTP_HOST properly setup?
AFAICT it is functioning exactly as designed. It returns the value of the Host:
header as sent by the client. Numerous experiments with phpinfo() have confirmed
According to the apache docs (and confirmed by the above mentioned experiments)
if UseCanonicalName is set to 'off' the SERVER_NAME variable is set to
equal HTTP_HOST. This works great in most all cases. If UseCanonicalName is set
to 'on' then SERVER_NAME is set to whatever 'ServerName' is set
to in the apache conf. Seeing as UseCanonicalName can be set in the virtual host
entry there is no problem doing something like this:
If Drupal used the SERVER_NAME variable then accessing the site should load the
hostname.com configuration regardless of what alias is accessed. Seeing as it
uses HTTP_HOST it will fail to load a configuration.
> Generally, for Drupal multisites to work under different Apache
> configurations, Drupal needs to rely more on the client's HTTP request
> rather than the server configuration. You can see a related issue in
I suppose it's swings and roundabouts really. Using HTTP_HOST provides a
globally predictable outcome. But if the user has access to the apache
configuration, either by support request or personally, then SERVER_NAME
provides a more configurable outcome.
I guess I'll just stick with symlinks (they can always be excluded from the
version control anyway).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development