Last modified: 2010-05-15 15:33:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T6395, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 4395 - MediaWiki forced me to use ugly URLs. Whether I refused, MediaWiki looped
MediaWiki forced me to use ugly URLs. Whether I refused, MediaWiki looped
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
1.4.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-27 02:01 UTC by Yvan Barthélemy
Modified: 2010-05-15 15:33 UTC (History)
0 users

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


Attachments

Description Yvan Barthélemy 2005-12-27 02:01:39 UTC
cgi was detected in php_sapi_name() and MediaWiki prevented my host to use it, resulting in infinite loop.

The story follows : I have set up MediaWiki in local and have made a script using MediaWiki. This script uses the cool URLs : 
http://server/index.php/Article. When I finished, I upload all that on my web hosting service, I re-configured MediaWiki on that 
server, and my script links were redirected on home of MediaWiki, with an ugly URL.
So, I checked LocalSettings and saw : $wgArticlePath = "$wgScript?title=$1";
I changed it to $wgArticlePath = "$wgScript/$1"; in the hope my URI would worked (I was very optimitic, since it is a string 
modification, and not a TRUE/FALSE modification... And, it didn't worked, it does infinite redirection instead of just displaying the 
article.
The 'error' is first to assume that if php_sapi_name() returns something with CGI, PATH_INFO can't work. This is false, in absolute. 
A possible workaround is to add this option in LocalSettings with a comment about that. An other way is to find an other way to 
check the support of path_info. An other way is to modify WebRequest to ignore wgUsePathInfo (but please don't do that, since 
it's crap...)
Comment 1 Rob Church 2005-12-27 02:04:20 UTC
PHP running as a CGI binary causes the pretty URLs not to work. That's why the
configuration script sets the $wgArticlePath value to the ugly ones when it
detects this. These cases have been tested.

If you went and changed the value against the recommendation, and this broke
your MediaWiki installation, that's your fault and not the software's. Try it
with the ugly URLs and see if this works.

Resolving INVALID.
Comment 2 Rob Church 2005-12-27 02:05:59 UTC
Just to be clear about it: the installer script forces the change once, when
writing out the configuration file. The software doesn't enforce it elsewhere.
Comment 3 Yvan Barthélemy 2005-12-27 12:21:35 UTC
There is no bug in MediaWiki about that that is just a possible enhancement. Sorry if I was not clear about that.

The problem is that MediaWiki can run with pretty URLs enabled in some cases. I was not saying it was not my fault, It was 
since I wanted to force the use of pretty URLs. I just recommanded to provide user a way to restore pretty URLs even if CGI 
was detected. In my case, pretty URLs work perfectly with MediaWiki, but MediaWiki prevented them to work by setting it to 
false by default for CGI installation :
$wgUsePathInfo = ( strpos( php_sapi_name(), 'cgi' ) === false );

Adding $wgUsePathInfo = false; in LocalSettings during installation with a comment specifying :
Pretty URL was disabled because your server is running PHP as a CGI binary. If you want to restore pretty URLs despite that, 
please make sure to set $wgUsePathInfo to true.
Doing this will allow unexperienced user to restore pretty URL support if possible, knowing this might not work.

Comment 4 Yvan Barthélemy 2005-12-27 12:29:39 UTC
To do it, just replace :
## If using PHP as a CGI module, use the ugly URLs.

with

## If using PHP as a CGI module, use the ugly URLs. To restore
## pretty URLs, make sure to also set $wgUsePathInfo to true.
Comment 5 Rob Church 2005-12-27 16:01:11 UTC
(In reply to comment #3)
> was detected. In my case, pretty URLs work perfectly with MediaWiki, but
MediaWiki prevented them to work by setting it to 
> false by default for CGI installation :
> $wgUsePathInfo = ( strpos( php_sapi_name(), 'cgi' ) === false );

No, what it set was $wgArticlePath = "$wgScript?title=$1" as opposed to
"$wgScript/$1" because _PRETTY URLS DO NOT NORMALLY WORK WHEN PHP IS RUN AS A
CGI BINARY_.

If users _know_ that pretty URLs can work, then they simply change this setting
and save LocalSettings.php. It's even commented so they know they can do that.
Comment 6 Yvan Barthélemy 2005-12-27 16:35:11 UTC
Since $wgUsePathInfo would be set to false, even if a user changes $wgArticlePath, this will not work. MediaWiki will ignore 
the PATH_INFO, and do infinite redirects unless $wgUsePathInfo is set to true.

According, my investigation, by default, each time a page is requested, $wgUsePathInfo is computed, and set to false if the 
server is running a CGI. Then, when a user request a page using path info (a pretty URL), which is the case with pretty 
URLs, WebRequest.php will ignore it, and index.php will try redirect to Home (which is impossible using pretty URL, since 
this will be ignored by MediaWiki, and will generate an infinite loop).

The worst is when a user request a page using a pretty URL, whether $wgArticlePath is set to pretty or ugly URL, he will be 
redirected to home rather to the page he requested, that is an unexpected behaviour. In my opinion, this URL should have 
been processed, and eventually redirected to an ugly URL if needed.

In my opinion, $wgUsePathInfo should be always set to true, unless $_SERVER['PATH_INFO'] can contains garbage, which I 
don't think that is the case.

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


Navigation
Links