Last modified: 2011-04-04 21:32:40 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 4570 - (AIX) index.php returns empty page when called with no arguments
(AIX) index.php returns empty page when called with no arguments
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.5.x
Other other
: High normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-12 08:33 UTC by Robert Kaiser
Modified: 2011-04-04 21:32 UTC (History)
1 user (show)

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


Attachments

Description Robert Kaiser 2006-01-12 08:33:43 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.
Comment 1 Brion Vibber 2006-01-12 08:35:54 UTC
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...
Comment 2 Rob Church 2006-01-12 13:51:11 UTC
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.
Comment 3 Robert Kaiser 2006-01-12 14:35:34 UTC
@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"?
Comment 4 Brion Vibber 2006-01-17 19:09:14 UTC
Do HTTP requests in telnet, or use a network sniffer, or use the Live HTTP 
Headers extension for Firefox, etc.
Comment 5 Robert Kaiser 2006-01-18 09:14:27 UTC
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?
Comment 6 Brion Vibber 2006-01-18 09:21:21 UTC
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.
Comment 7 Robert Kaiser 2006-01-27 09:48:56 UTC
Excellent. Thank you very much for your solution to this problem. 
Comment 8 Rob Church 2007-04-08 08:51:08 UTC
(Resolving on the basis of comment 7; INVALID since it was a configuration issue)

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


Navigation
Links