Last modified: 2011-04-04 21:32:40 UTC
The entry point to wikimedia in our environment is:
However, this URL only returns an empty page. The following URL works, however:
This means that whenever index.php is called without argument, it returns an
empty page and the browser throws an error message.
The same happens when I try to parse the file index.php directly on the server:
[wwwrun@wega97]/usr/local/apache/htdocs/wiki > php -e -f index.php
Our guess is that this problem is the root cause for an error message the
browser displays when we try to save an article.
Internet Explorer says: Page cannot be displayed.
Firefox says nothing, it tries to find more information through its inbuilt
search and fails.
The article is always saved, however, but after pressing the button the browser
doesn't get any valid data from the web server.
Version: 5.3 ML 02
MYSQL: Ver 12.22 Distrib 4.0.26, for ibm-aix220.127.116.11 (powerpc)
PHP: PHP 4.4.0 (cgi) (built: Sep 2 2005 16:00:02)
Zend Engine v1.3.0
Server version: Apache/1.3.20 (Unix)
Server built: Aug 20 2001 13:11:57
The binaries were not compiled on the server but downloaded as installable files
Apache doesn't have a built-in library for running php. The php binary is used
as an Apache CGI extension. There's no php mod or library available for our type
of operating system and platform.
Therefore, the Apache configuration has the following entries:
Action php-script /cgi-bin/php
AddHandler php-script .php
And, uh, yes, the Apache server is running on port 8081.
Check that the HTTP status codes and Location headers are being returned.
If you have trouble with these old versions of Apache & PHP try compiling your own...
Another suggestion. Check the value of $wgArticlePath in LocalSettings.php and
try changing it to
$wgArticlePath = "$wgScript?title=$1";
You'll find this line already commented-out, near the existing one.
@Brion Vibber: Thanks for the suggestion. However, I only have gcc (the GNU
compiler) for AIX,
and I never really succeeded compiling much of anything with that thing. It dies
right at the beginning of
the make process, barking about some strange additional qualifiers, really no
matter what I try to compile.
Thus compiling php and apache myself didn't work, I tried for three days until I
resolved to use the precompiled versions.
@Rob Church: Thank you too for your suggestion. The entry in LocalSettings.php
already looks like this:
## If using PHP as a CGI module, use the ugly URLs
# $wgArticlePath = "$wgScript/$1";
$wgArticlePath = "$wgScript?title=$1";
I tried both settings, and it doesn't change anything.
How do I "Check that the HTTP status codes and Location headers are being returned"?
Do HTTP requests in telnet, or use a network sniffer, or use the Live HTTP
Headers extension for Firefox, etc.
Thanks for letting me know what you meant earlier.
I sent the following request to the server:
[someone@spcws]/home/someone > telnet wega97 8081
Connected to wega97i.iv.brnet.de.
Escape character is '^]'.
GET http://172.16.1.97:8081/wiki/index.php HTTP/1.0
The reply was:
Date: Wed, 18 Jan 2006 09:00:05 GMT
Server: Apache/1.3.20 (Unix)
Cache-Control: private, must-revalidate, max-age=0
Last-Modified: Wed, 18 Jan 2006 09:00:05 GMT
This means that the web server answers with nothing or an empty page when I send
an HTTP request to
But it's not the web server's fault, because sending a request to retrieve a
different php page
GET http://172.16.1.97:8081/todo/index.php HTTP/1.0
This request sends back a To-Do list built using a php script.
Among other things I also tried adding index.php as a valid entry point for
DirectoryIndex index.html index.php
I am totally clueless as to how to proceed from here.
We still get an error message in Firefox when we edit a page, and for now we
resorted to living with it.
The error message is:
mogu.jp.org konnte nicht gefunden werden. Bitte überprüfen Sie den Namen und
versuchen Sie es nochmals."
("Warning: mogu.jp.org could not be found. Please verify the name and try again.")
This message is displayed because Firefox is trying to do some internal search
when an empty page is returned.
Internet Explorer just throws this error message:
"Die Seite kann nicht angezeigt werden."
("This page cannot be displayed.")
In this case, the error message from Internet Explorer is more to the point
because it really shows that the page was empty.
My guess is that index.php from wikimedia is not working correctly in our
environment if it is just called by itself without any arguments.
The reply looks ok, unless there's a server name problem. The key lines are:
^ This tells the client to load another URL; it will redirect you to the
canonical URL for the wiki's main page.
^ This is what the wiki thinks should be the proper URL for the main page.
Now, the thing I notice is that the hostname in the URL is not fully-qualified
("wega97"). If that is not the expected, reachable hostname for the server this
may indicate that Apache's ServerName directive is incorrectly set.
Either fiddle with the Apache configuration, or override the auto-detected
hostname in MediaWiki's LocalSettings.php like this:
$wgServer = "http://www.example.com";
Don't include any path information on it; this is just the protocol and hostname.
It's used when generating complete URLs pointing back to the wiki, such as the
RSS feeds and any internal HTTP redirects.
Excellent. Thank you very much for your solution to this problem.
(Resolving on the basis of comment 7; INVALID since it was a configuration issue)