Page MenuHomePhabricator

Should be able to modify $wgServerName in LocalSettings.php
Closed, DeclinedPublic


I don't know if this is a general problem or a particular issue with the way my
shared host is set up, but $wgServerName (and therefore the variables that
depend on it) is being calculated incorrectly.

The code picks the first variable from this list that is defined (falling back
on 'localhost' if none of them are):


My company wiki is located on a protected sub-domain at On our server the above variables are set
as follows:

$_SERVER['HOSTNAME']    = (not set)
$_SERVER['HTTP_HOST']   = ""
$_SERVER['SERVER_ADDR'] = (IP address)

The order of checks mean that the automatically generated value is
"" instead of just "" as it should
be. Because of the .htpasswd protection we are therefore asked to login twice,
as these are treated as separate domains.

I experienced the problem in 1.5.6, but I've checked HEAD and the code for
generating $wgServerName has not changed.

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:32 PM
bzimport set Reference to bz8866.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 3175
Patch for DefaultSettings.php

A patch to move the test for SERVER_NAME to after HTTP_HOST. This is a
complete fix, providing that this behaviour is acknowledged to be a bug, rather
than intended behaviour.


HTTP_HOST is unreliable generally as it is client-supplied; thus on a
configuration where strictly-enforced name-based virtual hosts are not being
used it may be possible for an attacker to poison caches (bad redirects, HTTP
response splitting, etc).

You probably should take a look at your Apache configuration and find out why
your ServerName is set differently to what you actually wanted to use.

OK - I will look into that and return here with my findings. Please leave this
bug open for the time being - I will update it when I've dug a little deeper.

marti wrote:

There is another reason why SERVER_NAME could be unreliable: when using HTTPS, the lighttpd web server sets SERVER_NAME to the SSL certificate's common name instead of the virtual host's name, which might be something like "*", thus again breaking redirects.

So, to allow serving over HTTP as well as HTTPS, one would have to set:

$wgServer = $wgProto . "://";

which is inelegant in my opinion. Changing $wgServerName alone has no effect, since its value is only used in LocalSettings.php to set $wgServer.

I would prefer either:

  1. preferring HTTP_HOST over SERVER_NAME, or
  2. making $wgServerName overridable, and thus assigning to $wgServer

Well, for handling the two-available-URLs case you really want to do a little more, introducing the concept of a canonical URL base that's distinct from the currently active URL. Otherwise you end up with some weird mixes of getting one or the other saved in caches, sent in e-mails, etc.

I did a little experimenting with this in a short branch:

Haven't done any further work on that.

marti wrote:

I see your point about cache corruption. I'll have a look at your SSL branch when I can find the time. Thanks.

Note that the issue with "www." being prepended to the domain (so "" is reported as "") seems to be a peculiarity with the way my server is setup, so I am getting round it by manually setting $wgServer.

As mentioned in comment 5, it would be better if I could just set $wgServerName rather than building $wgServer using the literal name, plus the protocol and port options, so I guess that issue still stands. I have modified the subject to make the current issue clearer.

(In reply to comment #7)

I have modified the subject

Well all I know is in bug 19593 I was able to modify $wgServerName in LocalSettings.php, so please modify the Summary again.

Marking as WONTFIX since $wgServerName was removed in r73950.

Added "blocks" just for reference to this already solved issue.