d_o_s_v() is, according to the documentation, a function to be used by CLI scripts for populating server variables. Of particular interest is the special "url" key, which is split up into host and path and written into the appropriate variables.

However, the structure goes like this:

  $defaults = array(
    'HTTP_HOST' => $url['host'],
    'SCRIPT_NAME' => $url['path'],
    // ...
  );

  $_SERVER = $variables + $_SERVER + $defaults;

First of all, this never works at all on the web, because $_SERVER contains both of these variables and overrides them implicitly since array addition is left-sided.

In CLI scripts, we see an even stranger effect: The HTTP_HOST is populated, because $_SERVER doesn't have it. But "SCRIPT_NAME" is in PHP CLI's $_SERVER, which means that while our "url" key overrides the HTTP_HOST, it doesn't do anything to SCRIPT_NAME.

These two variables need to be written into a separate array instead, which takes precedence over $_SERVER.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cburschka’s picture

Status: Active » Needs review
FileSize
1.22 KB

This is not a one-liner, and I may have made a logical error. But here's what I've changed:

1.) If $variables['url'] is passed, then its host and path will be used, and they will always override $_SERVER's HTTP_HOST and SCRIPT_NAME.
2.) If $variables['url'] is not passed, then HTTP_HOST will be supplemented (if it does not exist) as "localhost" (as before), while SCRIPT_NAME will remain unchanged (as before).

cburschka’s picture

I should have mentioned that the issue can currently be worked around by setting SCRIPT_NAME directly in the variables, but as the comment recommends the special "url" key, this should be fixed in order to make it work as advertised.

cburschka’s picture

Priority: Normal » Critical

This is still not fixed, and command-line installation is broken unless you use an annoying work-around.

c960657’s picture

First of all, this never works at all on the web, [...]

Why do you want to use it on the web? AFAIK the function is only relevant when Drupal is being run as a CLI script.

c960657’s picture

Apart from that I think the patch is good. Do you think it would be better easier to understand if you just update $_SERVER directly instead of introducing $url_override as an intermediate variable? If not, I think looks RTBC.

sun.core’s picture

Priority: Critical » Normal

If there is an annoying workaround, then this is not critical. Please read and understand Priority levels of Issues, thanks.

That said, this patch has the potential to get committed before release.

David_Rothstein’s picture

I just ran into this the other day - would definitely like to fix it :) Here is a revised patch that does what @c960657 suggests and also adds a test.

David_Rothstein’s picture

#7: bootstrap-dosv-557298-7.patch queued for re-testing.

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

Tests look to be testing the functionality properly, and they pass. I think the code is much cleaner this way and actually allow the use of the function as documented/intended.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.