Last modified: 2011-04-04 21:32:40 UTC
The entry point to wikimedia in our environment is: http://172.16.1.97:8081/wiki/index.php However, this URL only returns an empty page. The following URL works, however: http://172.16.1.97:8081/wiki/index.php?title=Hauptseite 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. Environment: OS: AIX Version: 5.3 ML 02 MYSQL: Ver 12.22 Distrib 4.0.26, for ibm-aix5.2.0.0 (powerpc) PHP: PHP 4.4.0 (cgi) (built: Sep 2 2005 16:00:02) Zend Engine v1.3.0 APACHE: 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 from www.bullfreeware.com 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: ------------snip------------- Listen 172.16.1.97:8081 Action php-script /cgi-bin/php AddHandler php-script .php ------------snap------------- 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 Trying... 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: HTTP/1.1 301 Date: Wed, 18 Jan 2006 09:00:05 GMT Server: Apache/1.3.20 (Unix) Cache-Control: private, must-revalidate, max-age=0 Expires: -1 Vary: Accept-Encoding,Cookie X-Powered-By: PHP/4.4.0 Last-Modified: Wed, 18 Jan 2006 09:00:05 GMT Location: http://wega97/wiki/index.php?title=Hauptseite Connection: close Content-Type: text/html Connection closed. This means that the web server answers with nothing or an empty page when I send an HTTP request to http://172.16.1.97:8081/wiki/index.php But it's not the web server's fault, because sending a request to retrieve a different php page is successful: 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 directories: -----SNIP httpd.conf----- <IfModule mod_dir.c> DirectoryIndex index.html index.php </IfModule> -----SNAP httpd.conf----- 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: "Warnung 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. Any ideas?
The reply looks ok, unless there's a server name problem. The key lines are: HTTP/1.1 301 ^ This tells the client to load another URL; it will redirect you to the canonical URL for the wiki's main page. Location: http://wega97/wiki/index.php?title=Hauptseite ^ 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)
