Last modified: 2010-05-15 15:37:53 UTC
I investigated PHP_INFO bug with binary CGI. Here are the test case used to patch the code. I hava installed wiki on the cgi server and modified LocalSettings.php to have URL in pretty format, and set $wgUsePathInfo to true to bypass the CGI check in DefaultSettings.php. Provided URL : http://wiki-server/mediawiki_dir/ Expected : http://wiki-server/mediawiki_dir/index.php/Home Result : http://wiki-server/mediawiki_dir/index.php/mediawiki_dir/index.php Provided URL : http://wiki-server/mediawiki_dir/index.php Expected : http://wiki-server/mediawiki_dir/index.php/Home Result : http://wiki-server/mediawiki_dir/index.php/mediawiki_dir/index.php Provided URL : http://wiki-server/mediawiki_dir/index.php/ Expected : http://wiki-server/mediawiki_dir/index.php/Home Result : http://wiki-server/mediawiki_dir/index.php/Home (working) Provided URL : http://wiki-server/mediawiki_dir/index.php/XXX Expected : http://wiki-server/mediawiki_dir/index.php/XXX Result : http://wiki-server/mediawiki_dir/index.php/XXX (working) I solved it. I will provide a patch for that as soon I know how to write patch. If needed, I will also prvide a patch to change default installation settings for CGI.
(In reply to comment #0) Can we confirm that's the case on all installations using all CGIs? Otherwise, your patch is going to break a lot more than it solves, for a lot more configurations. It appears that a dirty workaround may be needed. What is the value of php_sapi_name() on your configuration? (Special:Version - should be in parentheses after the PHP version)
I can't confirm this is the case on all CGI installation, this need to be investigated but I don't know how to to this kind of work. At this time, I can only consider the problem solved for me. php_sapi_name() returns 'cgi' on my host. The workaround applies on WebRequest.php and compares parts of REQUEST_URI and PATH_INFO. Here is my modified WebRequest(), if you see anything which might break on some configuration, please let me know… function WebRequest() { $this->checkMagicQuotes(); global $wgUsePathInfo; # Correct a bug with binary CGI installations of PHP if ( !(strpos( php_sapi_name(), 'cgi' ) === false) && $wgUsePathInfo ) { $exp_request = explode('?', $_SERVER['REQUEST_URI']); if (substr($exp_request[0], -1) == "/") { $dir_request = substr($exp_request[0], 0, -1); } else { $dir_request = dirname($exp_request[0]); } if (dirname($_SERVER['PATH_INFO']) == $dir_request) { # Path info has been defined to the script path... unset($_SERVER['PATH_INFO']); } } if( isset( $_SERVER['PATH_INFO'] ) && ($_SERVER['PATH_INFO'] != '') && $wgUsePathInfo ) { # Stuff it! $_GET['title'] = $_REQUEST['title'] = substr( $_SERVER['PATH_INFO'], 1 ); } }
I have investigated the phpinfo I found on the Web using CGI : There are some case where my method will allow pretty URL to work. There are many most cases where this should work, and my code will simply be useless. And there are some cases where this won't work since '/' is simply not supported by the server. However, there are some cases where PATH_INFO don't work properly but ORIG_PATH_INFO works (especially in some installations of 5.0.4-cgi, but not all). It needs more investigation to find a way to decide whether to use it. In every cases I saw, my code don't break anything. I think we can use that code, and modify config/index.php to add a comment in LocalSettings.php specific for cgi, fast- cgi explaining how to add support for pretty URLs. I think, I will send patches today or tomorrow...
Kind of hoping that title interpolation changes in 1.10/1.11 fix this, but it's hard to tell without a broken system to test. :) Resolving WORKSFORME; reopen with details if problems continue.
