[development] Loading configuration using 'SERVER_NAME' as opposed to 'HTTP_HOST'
adam.j.cooper at gmail.com
Mon Mar 16 18:40:42 UTC 2009
> This is more a support question and should be on the support list
> but see below.
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
> 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 that.
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
> 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).
More information about the development