If you've stumbled upon this post, it means that you ran into a common issue happening right after installing/upgrading to MediaWiki build 1.26.2 (and above) under a Windows/IIS environment. The problem arises everytime you try to request a URL containing special characters, such as colon or ampersand: the browser will try to load the page for 20-30 seconds, then it will timeout with a redirect loop error like the following:
This Webpage has a redirect loop
Error 310
ERR_TOO_MANY_REDIRECTS
... and so on. Since all MediaWiki's special pages contains at least a colon, this will most likely prevent you from running any of them.
The Problem
It's worth noticing that this issue is not related to the dreadful IIS 7.5 colon bug, which prevents older versions of IIS to properly handle URLs with colons (we mentioned it here, also providing a JavaScript-based fix). As a matter of fact, we're dealing with a completely different pair of shoes here: a regression bug most likely caused by this patch to the MediaWiki source code, shipped in 1.26.2 and above releases up to 1.27.0, where the value of the requested url is compared to what appears to be believed to be the canonical url:
|
1 2 3 4 5 6 7 |
$targetUrl = wfExpandUrl( $title->getFullURL(), PROTO_CURRENT ); if ( $targetUrl != $request->getFullRequestURL() ) { $output->setSquidMaxage( 1200 ); $output->redirect( $targetUrl, '301' ); return true; } |
The problem with this code is that it will always fail under IIS due to the fact that the request URL is determined using the $_SERVER['REQUEST_URI'] environment variable, which happens to behave differently between Apache and IIS when it contains URL encoded characters.
The Solution
Unfortunately, this issue can't be addressed at configuration level by changing the $wgUsePathInfo or $wgArticlePath values, as it has nothing to do with them: the only viable workaround I found for now is to apply the following change to the /includes/MediaWiki.php code from this (lines 344-348):
|
1 2 3 4 5 |
if ( $targetUrl != $request->getFullRequestURL() ) { $output->setCdnMaxage( 1200 ); $output->redirect( $targetUrl, '301' ); return true; } |
to this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
if (strpos(strtolower($_SERVER["SERVER_SOFTWARE"]), "microsoft-iis") !== false) { // The script is running under IIS: urldecode everything to fix $_SERVER['REQUEST_URI'] wrong return value. // Ref.: https://phabricator.wikimedia.org/T127734 if ( urldecode($targetUrl) != urldecode($request->getFullRequestURL()) ) { $output->setCdnMaxage( 1200 ); $output->redirect( $targetUrl, '301' ); return true; } } else { // The script is not running under IIS: use the default behaviour if ( $targetUrl != $request->getFullRequestURL() ) { $output->setCdnMaxage( 1200 ); $output->redirect( $targetUrl, '301' ); return true; } } |
This might be a bit extreme, since it means changing the core MediaWiki source code, but it will fix the issue for the time being. Let's hope that the upcoming builds of MediaWiki will have it fixed accordingly.
Hi, can I apply your fix on Apache 2.4? Should I change something?
No idea, sorry: I don’t use Apache 2.4… but I guess it would work too.
Hi,
Was this fixed in a later version of MediaWiki than 1.27? Can we just upgrade to fix now? Thx
Yes, I had no issues with MW 1.27 so far.