Last modified: 2014-04-11 16:03:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 61 - Improve hostname autodetection
Improve hostname autodetection
Status: NEW
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 273 1077 (view as bug list)
Depends on:
Blocks: 18274
  Show dependency treegraph
 
Reported: 2004-08-16 02:06 UTC by Brion Vibber
Modified: 2014-04-11 16:03 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2004-08-16 02:06:01 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.)
Comment 1 JeLuF 2004-08-17 06:03:49 UTC
`hostname` normally returns only the "local" part of the name, e.g. "zwinger"
for "zwinger.wikipedia.org". Error messages would still be the same.
Comment 2 Brion Vibber 2004-08-17 06:10:38 UTC
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?
Comment 3 Paul Scanlon 2004-08-17 20:36:43 UTC
(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
Comment 4 Brion Vibber 2004-08-17 20:54:30 UTC
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'?
Comment 5 Paul Scanlon 2004-08-18 17:58:05 UTC
(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.
Comment 6 Brion Vibber 2004-09-02 22:09:19 UTC
*** Bug 273 has been marked as a duplicate of this bug. ***
Comment 7 Brion Vibber 2004-12-11 23:49:22 UTC
*** Bug 1077 has been marked as a duplicate of this bug. ***
Comment 8 Bodo Thiesen 2004-12-11 23:54:06 UTC
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'];
Comment 9 Bodo Thiesen 2004-12-12 00:11:08 UTC
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
Comment 10 Brion Vibber 2008-12-30 02:00:17 UTC
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...
Comment 11 Quim Gil 2014-04-11 16:03:38 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links