Last modified: 2011-03-13 18:05:17 UTC
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): $_SERVER['SERVER_NAME'] $_SERVER['HOSTNAME'] $_SERVER['HTTP_HOST'] $_SERVER['SERVER_ADDR'] My company wiki is located on a protected sub-domain at http://internal.mydomain.com/wiki/. On our server the above variables are set as follows: $_SERVER['SERVER_NAME'] = "www.internal.mydomain.com" $_SERVER['HOSTNAME'] = (not set) $_SERVER['HTTP_HOST'] = "internal.mydomain.com" $_SERVER['SERVER_ADDR'] = (IP address) The order of checks mean that the automatically generated value is "www.internal.mydomain.com" instead of just "internal.mydomain.com" 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.
Created attachment 3175 [details] 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.
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 "*.example.org", thus again breaking redirects. So, to allow serving over HTTP as well as HTTPS, one would have to set: $wgServer = $wgProto . "://wiki.example.org"; 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: http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=23079 http://svn.wikimedia.org/viewvc/mediawiki/branches/ssl-login-work/ Haven't done any further work on that.
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 "internal.mydomain.com" is reported as "www.internal.mydomain.com") 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.
