jeluf wrote:

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?

asvr90 wrote:

(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'?

asvr90 wrote:

(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. ***

bothie wrote:

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'];

bothie wrote:

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.

I suggest to check whether http://wikiapiary.com/ collects $wgServer information (from action=query&meta=siteinfo&siprop=general) and to query how many wikis are misconfigured. If this is a common issue during installing, at least some sysadmins have probably neglected to correct it.

Related in some way: T72306