Last modified: 2014-04-11 16:03:38 UTC
A surprising number of systems are misconfigured such that Apache reports the server name as 'localhost' or '127.0.0.1'. MediaWiki then uses this when creating fully qualified URLs such as for redirection from index.php to the main page, and the resulting browser error messages tend to be non-intuitive. $wgServer can be overridden manually, but that's a pain. At the least, we should detect the worst-case condition and make it easy to override in config/index.php. If possible, we might explore alternate ways to get the hostname (`hostname` for instance, or other env vars.)
`hostname` normally returns only the "local" part of the name, e.g. "zwinger" for "zwinger.wikipedia.org". Error messages would still be the same.
My quick spotcheck on a Mac OS X box, a Solaris box, and two Linux boxes shows a fully qualified hostname returned from the 'hostname' command on each. Can you confirm?
(In reply to comment #2) > My quick spotcheck on a Mac OS X box, a Solaris box, and two Linux boxes shows a fully > qualified hostname returned from the 'hostname' command on each. Can you confirm? Just chipping in. hostname -f should give the fully qualified domain name, on linux 2.4.18 at least
There's no -f option on Mac OS X or Solaris. Unix is such fun. ;) Could you check what 'uname -n' gets you on these Linux boxes that don't return a full domain name from 'hostname'?
(In reply to comment #4) > There's no -f option on Mac OS X or Solaris. Unix is such fun. ;) > Could you check what 'uname -n' gets you on these Linux boxes that don't return a full domain name > from 'hostname'? Ok. All this on linux 2.4.18. I have changed my hostname to 'mars', my domain is 'local'. So the FQDN is mars.local. Here are results from different commands. hostname -> mars hostname -f -> mars.local uname -n -> mars uname -a -> Linux mars 2.4.18-3 #1 Thu Apr 18 07:32:41 EDT 2002 i686 unknown dnsdomainname -> local Hope this helps.
*** Bug 273 has been marked as a duplicate of this bug. ***
*** Bug 1077 has been marked as a duplicate of this bug. ***
On request of Brion, I repost the Patch from http://bugzilla.wikipedia.org/show_bug.cgi?id=1077 here: (The patch is also available for download at http://bothie.sharedaemon.org/temp/mediawiki-1.3.8-bt1.diff - just for the case of problems with tabs etc.) diff -ur mediawiki-1.3.8/includes/DefaultSettings.php mediawiki/includes/DefaultSettings.php --- mediawiki-1.3.8/includes/DefaultSettings.php 2004-11-16 00:59:13.000000000 +0100 +++ mediawiki/includes/DefaultSettings.php 2004-12-12 00:18:17.000000000 +0100 @@ -14,8 +14,11 @@ $wgSitename = 'MediaWiki'; # Please customize! $wgMetaNamespace = FALSE; # will be same as you set $wgSitename - -if( isset( $_SERVER['SERVER_NAME'] ) ) { +if (isset( $_SERVER["HTTP_HOST"] )) { + # First try to get the ServerName from the only point, which is + # correct in ANY case. Only if that faily, try other guesses. + $wgServerName = $_SERVER["HTTP_HOST"]; +} elseif( isset( $_SERVER['SERVER_NAME'] ) ) { $wgServerName = $_SERVER['SERVER_NAME']; } elseif( isset( $_SERVER['HOSTNAME'] ) ) { $wgServerName = $_SERVER['HOSTNAME'];
My patch was considered insecure: <brion> can you guarantee that http_host is safe, considering that it's client-provided? <brion> (http response splitting, html injection, cache poisoning, phishing takeover possibilities) It should be save because redirects will be tagged as "must revalidate". <brion> to the client, yes. but in squid mode, the squid will keep output. <brion> in file cache mode, some output is saved to disk and re-served to other clients. As headers are most probably not file cached we can assume it to be save when not using "squid mode", but use the patch on your own risk. Better set up your system correctly to report the correct domain. Regards, Bodo
HTTP 'Host' header and SERVER_NAME both have the problem of not providing a useful result for runtime autodetection for command-line scripts. To the extend that we may include things like {{SERVERNAME}} or {{FULLURL}} into parser cache data, or when creating static HTML dumps or such, that might be a bit annoying. :( On the other hand I hate hardcoding these sorts of things at configuration time, since those then break when wikis get moved to a new hostname deliberately. Sigh...
Is this still a problem nowadays, almost ten years after this report was filed? CCing Markus & Mark, since this is related to MediaWiki releases for 3rd parties.
