Loading configuration using 'SERVER_NAME' as opposed to 'HTTP_HOST'
Hello all, It's a (very) long time since I posted to this list. So please excuse me if I'm breaking etiquette. I'm attempting to set up a development environment that suits my way of working. Using a VMware virtual machine (that is as close a replica to my VPS as possible) I've set up an apache instance and am adding virtual hosts to it as I go. Up until now I've had no issue bring across my current sites. They all are single sites and so have been set up in the 'default' configuration. I can add an entry to my host machines hosts file (say 'sitename.dev') and everything works great. The problem now is that I have come across one of my multisite configurations. I figured I could just set the virtual host configuration to have ServerName as my site name (sitename) and then ServerAlias in the name I would be accessing it as (sitename.dev). Setting UseCanonicalName to 'on' would let me access the site as I would expect. Except, despite this setting SERVER_NAME to the value I expect (sitename) my drupal configuration refuses to load. I took a look in the bootstrap file and found that the configuration directory is loaded from HTTP_HOST. TL;DR. So my question is this, why does drupal load it's configuration using HTTP_HOST as opposed to SERVER_NAME? Surely SERVER_NAME would allow more flexibility and more direct control? Would a patch changing this have any chance of being looked at? Thanks Adam
On Sun, Mar 15, 2009 at 8:42 PM, Adam Cooper <adam.j.cooper@gmail.com> wrote:
Hello all,
It's a (very) long time since I posted to this list. So please excuse me if I'm breaking etiquette. I'm attempting to set up a development environment that suits my way of working. Using a VMware virtual machine (that is as close a replica to my VPS as possible) I've set up an apache instance and am adding virtual hosts to it as I go. Up until now I've had no issue bring across my current sites. They all are single sites and so have been set up in the 'default' configuration. I can add an entry to my host machines hosts file (say 'sitename.dev') and everything works great.
The problem now is that I have come across one of my multisite configurations. I figured I could just set the virtual host configuration to have ServerName as my site name (sitename) and then ServerAlias in the name I would be accessing it as (sitename.dev). Setting UseCanonicalName to 'on' would let me access the site as I would expect.
Except, despite this setting SERVER_NAME to the value I expect (sitename) my drupal configuration refuses to load. I took a look in the bootstrap file and found that the configuration directory is loaded from HTTP_HOST.
TL;DR.
So my question is this, why does drupal load it's configuration using HTTP_HOST as opposed to SERVER_NAME? Surely SERVER_NAME would allow more flexibility and more direct control? Would a patch changing this have any chance of being looked at?
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
Thanks Adam
While this may be less clean than desired, how about a symlink from drupal/sites/sitename.dev to drupal/sites/sitename.com ? Surely this would achieve a similar result with no downside to that being deployed on the server. -Mike __________________ Michael Prasuhn 503.488.5433 office 714.356.0168 cell 503.661.7574 home mike@mikeyp.net http://mikeyp.net
While this may be less clean than desired, how about a symlink from drupal/sites/sitename.dev to drupal/sites/sitename.com ?
This had been my first thought and will probably end up being my solution (though as you said it is not as clean as I had hoped). I had posted this question in order to gauge why things are done the way they are and if there was any scope for change. Thanks Adam This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
On Mon, Mar 16, 2009 at 11:39 AM, Adam Cooper <adam.j.cooper@gmail.com> wrote:
While this may be less clean than desired, how about a symlink from drupal/sites/sitename.dev to drupal/sites/sitename.com ?
This had been my first thought and will probably end up being my solution (though as you said it is not as clean as I had hoped).
I had posted this question in order to gauge why things are done the way they are and if there was any scope for change.
To expand a bit on my first answer, I think it is not desirable to have the right names for the directories under /sites depend on whether you have set UseCanonicalName to On or Off to match the ServerName or the ServerAlias. Most users have no control over this settings and are not even aware of its existence. The right names for the directories under /sites should follow some simple unconditional rules, and using HTTP_HOST allows that and provides the maximum flexibility.
Thanks Adam
This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
Using a symlink will result in modules, themes and files having an incorrect path stored in the database. When you move the site live you'll need to have your dev symlink in place for the site to function. You could, of course, change all the entries in files and system tables to reflect the change (along with any color module variables). Yuck... too much work. Instead of symlinks, set your development machine's 'hosts' file (/etc/hosts on linux and %WINDOWS%/system32/drivers/etc/hosts on windows) to have sitename.com go to 127.0.0.1 instead of the live site. You can remove the 'hosts' entry and restart your browser to reach the live site again. An alternative to this is to use sites/sitename.com then have dev.sitename.com go to 127.0.0.1 and it'll pick up that site directory anyway. Just remember to set your VirtualHost directive to accept dev.sitename.com as a ServerAlias. -- Sammy Spets Synerger http://synerger.com Michael Prasuhn wrote:
While this may be less clean than desired, how about a symlink from drupal/sites/sitename.dev to drupal/sites/sitename.com ?
Surely this would achieve a similar result with no downside to that being deployed on the server.
-Mike
__________________ Michael Prasuhn 503.488.5433 office 714.356.0168 cell 503.661.7574 home mike@mikeyp.net http://mikeyp.net
On Monday 16 March 2009 8:51:30 pm Sammy Spets wrote:
Using a symlink will result in modules, themes and files having an incorrect path stored in the database. When you move the site live you'll need to have your dev symlink in place for the site to function. You could, of course, change all the entries in files and system tables to reflect the change (along with any color module variables). Yuck... too much work.
The best solution is a backport of this D7 patch: http://drupal.org/node/231298 I use it on most of my multi-sites. :-) -- Larry Garfield larry@garfieldtech.com
Quoting Larry Garfield <larry@garfieldtech.com>:
On Monday 16 March 2009 8:51:30 pm Sammy Spets wrote:
Using a symlink will result in modules, themes and files having an incorrect path stored in the database. When you move the site live you'll need to have your dev symlink in place for the site to function. You could, of course, change all the entries in files and system tables to reflect the change (along with any color module variables). Yuck... too much work.
The best solution is a backport of this D7 patch:
I use it on most of my multi-sites. :-)
I think the better solution to this is to not store the files/whatever/file in the DB row and store only file. The variables tell where the files are located so storing the path to the file in the row is a normalization issue. I just moved a site from one host service to another and the location for the files changed. Needless to say I had to update the user rows for the avatar's no less. If the variables were used always to create the path and only the file name stored in the DB then moving the files directory should have been a simple change to the configuration. I don't have time to work on a patch for this idea at the moment but I do have it on my round tuit list. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://www.4offer.biz/
On Tue, Mar 17, 2009 at 5:51 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
I think the better solution to this is to not store the files/whatever/file in the DB row and store only file. The variables tell where the files are located so storing the path to the file in the row is a normalization issue. I just moved a site from one host service to another and the location for the files changed. Needless to say I had to update the user rows for the avatar's no less. If the variables were used always to create the path and only the file name stored in the DB then moving the files directory should have been a simple change to the configuration. I don't have time to work on a patch for this idea at the moment but I do have it on my round tuit list.
As with most Drupal problems there's already an issue for that: http://drupal.org/node/366464 Looking forward to seeing you in the issue queue, andrew
Quoting andrew morton <drewish@katherinehouse.com>:
On Tue, Mar 17, 2009 at 5:51 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
I think the better solution to this is to not store the files/whatever/file in the DB row and store only file. The variables tell where the files are located so storing the path to the file in the row is a normalization issue. I just moved a site from one host service to another and the location for the files changed. Needless to say I had to update the user rows for the avatar's no less. If the variables were used always to create the path and only the file name stored in the DB then moving the files directory should have been a simple change to the configuration. I don't have time to work on a patch for this idea at the moment but I do have it on my round tuit list.
As with most Drupal problems there's already an issue for that: http://drupal.org/node/366464
Looking forward to seeing you in the issue queue, andrew
Thanks Andrew. As I said, I don't have time at the moment but I visited the issue and subscribed. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://www.4offer.biz/
Quoting Adam Cooper <adam.j.cooper@gmail.com>: This is more a support question and should be on the support list but see below.
The problem now is that I have come across one of my multisite configurations. I figured I could just set the virtual host configuration to have ServerName as my site name (sitename) and then ServerAlias in the name I would be accessing it as (sitename.dev). Setting UseCanonicalName to 'on' would let me access the site as I would expect.
Except, despite this setting SERVER_NAME to the value I expect (sitename) my drupal configuration refuses to load. I took a look in the bootstrap file and found that the configuration directory is loaded from HTTP_HOST.
Usually I find the issue with this stems from the fact that the strings for the site directory in sites/ cannot be constructed from the HTTP_HOST string. I usually resolve this issue with symlinks to match what is expected. For instance www.sample.com vs sample.com and I created a www.sample.com directory under sites.
TL;DR.
So my question is this, why does drupal load it's configuration using HTTP_HOST as opposed to SERVER_NAME? Surely SERVER_NAME would allow more flexibility and more direct control? Would a patch changing this have any chance of being looked at?
My question back to you is why isn't HTTP_HOST properly setup? -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://www.4offer.biz/
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. I guess I'll just stick with symlinks (they can always be excluded from the version control anyway). Thanks Adam
On Mon, Mar 16, 2009 at 8:40 PM, Adam Cooper <adam.j.cooper@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
Quoting Cog Rusty <cog.rusty@gmail.com>:
<VirtualHost *:80> UseCanonicalName On
ServerName hostname.com ServerAlias hostname.dev </VirtualHost>
--8<-- 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.
The problem isn't getting to index.php the problem is getting to sites/hostname.com from a request for hostname.dev. If SERVER_NAME is also considered but after HTTP_HOST then we have the best of both worlds. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://www.4offer.biz/
Quoting Adam Cooper <adam.j.cooper@gmail.com>:
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?
These types of questions are presented more as a feature request in an issue queue.
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>
Based on the http://drupal.org/node/262920 issue sited below changing to <VirtualHost *:80> UseCanonicalName Off ServerName hostname.dev ServerAlias hostname.com </VirtualHost> Should work for you.
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.
I don't dislike your proposal maybe a combination of the two would be a good solution with HTTP_HOST being used first. Work up a patch for D7 and see where it goes. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://www.4offer.biz/
Hi 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@gmail.com> wrote: From: Adam Cooper <adam.j.cooper@gmail.com> Subject: Re: [development] Loading configuration using 'SERVER_NAME' as opposed to 'HTTP_HOST' To: development@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 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. I guess I'll just stick with symlinks (they can always be excluded from the version control anyway). Thanks Adam
participants (8)
-
Adam Cooper -
andrew morton -
Cog Rusty -
David Stein -
Earnie Boyd -
Larry Garfield -
Michael Prasuhn -
Sammy Spets