[development] Loading configuration using 'SERVER_NAME' as opposed to 'HTTP_HOST'

[Cog Rusty]

On Mon, Mar 16, 2009 at 8:40 PM, Adam Cooper <adam.j.cooper at gmail.com> wrote:
>> 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 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 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:
>
> <VirtualHost *:80>
>        UseCanonicalName On
>
>        ServerName hostname.com
>        ServerAlias hostname.dev
> </VirtualHost>
>
> 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
>> http://drupal.org/node/262920
>
> 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.


Maybe using SERVER_NAME can be considered more configurable on the
server's side, but not on Drupal's side. It makes Drupal's
configuration more dependent on the server's settings, which could
puzzle many people. Using HTTP_HOST the domain can be whatever you
want as long as you can point it to Drupal's index.php by any means
which don't alter the HTTP request.


> I guess I'll just stick with symlinks (they can always be excluded from the
> version control anyway).
>
> Thanks
> Adam
>
>