Last modified: 2010-05-15 15:48:15 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 8847 - Redirect loop detected on Section Edit
Redirect loop detected on Section Edit
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
PC Windows 2000
: Normal major with 1 vote (vote)
: ---
Assigned To: Brion Vibber
Depends on:
  Show dependency treegraph
Reported: 2007-02-01 17:11 UTC by Kris Shaw
Modified: 2010-05-15 15:48 UTC (History)
1 user (show)

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

Patch to WebRequest.php which hopefully fixes this (717 bytes, patch)
2007-02-23 19:14 UTC, Brion Vibber

Description Kris Shaw 2007-02-01 17:11:42 UTC
System: Windows 2000 server, PHP 5.2.0 ISAPI, MediaWiki 1.9.1

$wgArticlePath      = "$wgScript?title=$1";
$wgUsePathInfo      = false;

Editing and then saving a complete page works without error. However, choosing to edit a specific 
section reports a "Redirect loop detected!" loop error when saving. Refreshing the page confirms that it 
was saved sucessfully.

Commenting out the loop detection code in Wiki.php removes the error (and there isn't a loop either).

Kris Shaw.
Comment 1 Mark Gillespie 2007-02-07 16:32:03 UTC
Also seeing this problem.

IIS5, Windows 2000 server.  MediaWiki 1.9.1

Never had this issue before the 1.9.x update.
Comment 2 Mark Gillespie 2007-02-13 10:29:18 UTC
Still no resolution?  This issue is killing us, I get user reports all the time.  I don't suppose someone can send me a hacked wiki.php, I have looked 
at all those nested if blocks, and really unsure which way to hack it myself..

Raising the sevirity, as I know understand how to reproduce it, and how many users of my Wiki are affected...
Comment 3 Brion Vibber 2007-02-13 23:04:46 UTC
I'll see if I can get my Windows/IIS test VM up and try this out.
Comment 4 Brion Vibber 2007-02-14 00:32:12 UTC
Testing IIS 6, Windows 2k3, PHP 5.2.0 set up as cgi/fcgi. No problems.

Will try reconfiguring for ISAPI...
Comment 5 Brion Vibber 2007-02-14 00:37:03 UTC
IIS 6, Windows 2k3, PHP 5.2.0 set up as ISAPI. No problems.

Is this specific to IIS 5? I have no way to test IIS 5 currently...
Comment 6 Mark Gillespie 2007-02-14 08:59:42 UTC
II55, ISAPI, Win2k server
Comment 7 Mark Gillespie 2007-02-14 08:59:56 UTC
II55, ISAPI, Win2k server
Comment 8 Kris Shaw 2007-02-14 14:54:20 UTC
I'll try it in a Windows 2003 server with the same config files and database and see if I get the same problem. Is 
there any debugging information I can get that would be helpful?
Comment 9 Brion Vibber 2007-02-14 17:34:05 UTC
First, the exact error message displayed.

Second, the output of this script:

echo "<br>REQUEST_URI: ";
echo htmlspecialchars( @$_SERVER['REQUEST_URI'] );
echo "<br>SCRIPT_NAME: ";
echo htmlspecialchars( @$_SERVER['SCRIPT_NAME'] );
echo "<br>QUERY_STRING: ";
echo htmlspecialchars( @$_SERVER['QUERY_STRING'] );

Save it as loop.php and go to url such as:

Normall you should get something like this:

REQUEST_URI: /wiki/loop.php?title=Something&action=edit&section=1
SCRIPT_NAME: /wiki/loop.php
QUERY_STRING: title=Something&action=edit&section=1

On IIS configs where REQUEST_URI doesn't work then you should see this instead:

SCRIPT_NAME: /wiki/loop.php
QUERY_STRING: title=Something&action=edit&section=1

That ought to work fine with the IIS fix code in the latest versions.
Comment 10 Mark Gillespie 2007-02-14 17:40:45 UTC
REQUEST_URI: /loop.php?title=Something&action=edit&section=1
SCRIPT_NAME: /loop.php
QUERY_STRING: title=Something&action=edit&section=1
Comment 11 Kris Shaw 2007-02-14 17:41:22 UTC

OK, below is the output from loop.php:

REQUEST_URI: /loop.php?title=Something&action=edit&section=1
SCRIPT_NAME: /loop.php
QUERY_STRING: title=Something&action=edit&section=1


The actual error displayed on the screen is:

Internal error
Redirect loop detected!

This means the wiki got confused about what page was requested; this sometimes happens when moving a wiki to a new 
server or changing the server configuration.

Your web server was detected as possibly not supporting URL path components (PATH_INFO) correctly; check your 
LocalSettings.php for a customized $wgArticlePath setting and/or toggle $wgUsePathInfo to true.



Comment 12 Mark Gillespie 2007-02-14 17:44:40 UTC
Exact Error:

Internal Error

Redirect loop detected!

This means the wiki got confused about what page was requested; this sometimes happens when moving a 
wiki to a news server or changing server configuration.

Your web server was detected as possibly not supporting URL path components (PATH_INFO) correctly, check 
your LocalSettings.php for a customized $wgArticlePath setting and/or toggle $wgUsePathInfo to true.
Comment 13 Brion Vibber 2007-02-14 17:45:14 UTC
Looks like it should be fine, then.

I'll need to see your complete configuration files and the exact URLs to your
wikis... If you've done anything funny with rewriting, etc I need to know.
Comment 14 Kris Shaw 2007-02-14 17:51:27 UTC

The configuration of the server is below, although I've xxx'd the database server details etc. The Wiki is internal, 
but is accessed using an internal FQDN to the web server.




# This file was automatically generated by the MediaWiki installer.
# If you make manual changes, please keep track in case you need to
# recreate them later.

$IP = "E:\\Websites\\xxx-Wiki";
ini_set( "include_path", ".;$IP;$IP/includes;$IP/languages" );
require_once( "includes/DefaultSettings.php" );

# If PHP's memory limit is very low, some operations may fail.
# ini_set( 'memory_limit', '20M' );

if ( $wgCommandLineMode ) {
	if ( isset( $_SERVER ) && array_key_exists( 'REQUEST_METHOD', $_SERVER ) ) {
		die( "This script must be run from the command line\n" );
} elseif ( empty( $wgNoOutputBuffer ) ) {
	## Compress output if the browser supports it
	if( !ini_get( 'zlib.output_compression' ) ) @ob_start( 'ob_gzhandler' );

$wgSitename         = "XXX-Wiki";

$wgRawHtml = true;

$wgScriptPath	    = "";
$wgScript           = "$wgScriptPath/index.php";
$wgRedirectScript   = "$wgScriptPath/redirect.php";

## If using PHP as a CGI module, use the ugly URLs
# $wgArticlePath      = "$wgScript/$1";
#$wgArticlePath      = "$wgScript?title=$1";
#$wgUsePathInfo      = false;

$wgStylePath        = "$wgScriptPath/skins";
$wgStyleDirectory   = "$IP/skins";
$wgLogo             = "$wgStylePath/common/images/xxx-xxx-logo.gif";

$wgUploadPath       = "$wgScriptPath/images";
$wgUploadDirectory  = "$IP/images";

$wgEnableEmail = true;
$wgEnableUserEmail = true;

$wgEmergencyContact = "";
$wgPasswordSender	= "";

## For a detailed description of the following switches see
## and
## There are many more options for fine tuning available see
## /includes/DefaultSettings.php
## UPO means: this is also a user preference option
$wgEnotifUserTalk = true; # UPO
$wgEnotifWatchlist = true; # UPO
$wgEmailAuthentication = true;

$wgDBserver         = "xxx";
$wgDBname           = "xxx";
$wgDBuser           = "xxx";
$wgDBpassword       = "xxx";
$wgDBprefix         = "xxx_";

# If you're on MySQL 3.x, this next line must be FALSE:
$wgDBmysql4 = true;

## Shared memory settings
$wgMainCacheType = CACHE_NONE;
$wgMemCachedServers = array();

## To enable image uploads, make sure the 'images' directory
## is writable, then uncomment this:
$wgEnableUploads		= true;
$wgUseImageResize		= true;
# $wgUseImageMagick = true;
# $wgImageMagickConvertCommand = "/usr/bin/convert";
$wgGroupPermissions['*' ]['upload']          = true;

$wgStrictFileExtensions = false;

## If you want to use image uploads under safe mode,
## create the directories images/archive, images/thumb and
## images/temp, and make them all writable. Then uncomment
## this, if it's not already uncommented:
# $wgHashedUploadDirectory = false;

## If you have the appropriate support software installed
## you can enable inline LaTeX equations:
# $wgUseTeX			= true;
$wgMathPath         = "{$wgUploadPath}/math";
$wgMathDirectory    = "{$wgUploadDirectory}/math";
$wgTmpDirectory     = "{$wgUploadDirectory}/tmp";

$wgLocalInterwiki   = $wgSitename;

$wgLanguageCode = "en";

$wgProxyKey = "5231524351e4dbf370b332454d27d1641ca8ba802dd11703dcf16205da0d76f";

## Default skin: you can change the default skin. Use the internal symbolic
## names, ie 'standard', 'nostalgia', 'cologneblue', 'monobook':
# $wgDefaultSkin = 'monobook';

## For attaching licensing metadata to pages, and displaying an
## appropriate copyright notice / icon. GNU Free Documentation
## License and Creative Commons licenses are supported so far.
# $wgEnableCreativeCommonsRdf = true;
$wgRightsPage = ""; # Set to the title of a wiki page that describes your license/copyright
$wgRightsUrl = "";
$wgRightsText = "";
$wgRightsIcon = "";
# $wgRightsCode = ""; # Not yet used

$wgDiff3 = "";

$wgUrlProtocols = array(
	'telnet://', // Well if we're going to support the above.. -ævar
	'nntp://', // @bug 3808 RFC 1738

Comment 15 Kris Shaw 2007-02-14 17:57:43 UTC
One thing I've noticed is that the '#' symbol isn't in the URL variables, eg:


(which would be the URL displayed in IE when the loop error is displayed, but with index.php rather than loop.php) 

REQUEST_URI: /loop.php?title=Sand_Pit
SCRIPT_NAME: /loop.php
QUERY_STRING: title=Sand_Pit

I don't know if that causes problems for section editing though.


Comment 16 Mark Gillespie 2007-02-22 09:52:38 UTC
Kris, any chance of sending me a copy of your hacked Wiki.php, this is becoming a show stopper for us.  I get quite a few mails daily about this problem.

m a r k  g i l l e s p i e at d e k dot c o m

Comment 17 Brion Vibber 2007-02-22 18:25:09 UTC
Kris, it's normal that the # part isn't sent to the server.
(If it *were* that might cause the bug, perhaps? But it isn't.)
Nothing looks particularly suspicious in the config or test
output above, either.

Hopefully we'll be able to test against IIS 5.x in a couple weeks,
but currently I've still got no access to such a system to test...
Comment 18 Kris Shaw 2007-02-23 17:56:02 UTC
Hello Brion,

I put some echo's into Wiki.php, just before

if( $targetUrl == $wgRequest->getFullRequestURL()

The echo's were:
 echo $wgRequest->getFullRequestURL()."<br>";
 echo $targetUrl."<br>";
 echo "<br>REQUEST_URI: ";
 echo htmlspecialchars( @$_SERVER['REQUEST_URI'] );
 echo "<br>SCRIPT_NAME: ";
 echo htmlspecialchars( @$_SERVER['SCRIPT_NAME'] );
 echo "<br>QUERY_STRING: ";
 echo htmlspecialchars( @$_SERVER['QUERY_STRING'] );
 echo "<br>PATH_INFO: ";
 echo htmlspecialchars( @$_SERVER['PATH_INFO'] );

and interestingly I got the following result back:

REQUEST_URI: /index.php?title=Sand_Pit#Test
SCRIPT_NAME: /index.php
QUERY_STRING: title=Sand_Pit#Test

However, based on you comments above, the # shouldn't be in the URL?


Comment 19 Brion Vibber 2007-02-23 19:02:15 UTC
Ahhhhhhh ugh. :D

Ok, doing some quick testing...

IIS 6/Win2003 w/ PHP 5.2.0/ISAPI does keep the fragment (#whatever) through on
REQUEST_URI and QUERY_STRING if it's present in the actual HTTP request line.

(lighttpd w/ PHP 5.2.1/FastCGI on my main text box keeps it through on

However I don't see either IE 7 or Firefox sending the fragment, either from
direct navigation or an HTTP redirect. Don't have an IE 6 to test at the moment
on this box.

Looks like to be safe we should look for and strip a fragment when checking the
Comment 20 Brion Vibber 2007-02-23 19:14:00 UTC
Created attachment 3259 [details]
Patch to WebRequest.php which hopefully fixes this

Can you guys test this patch? Should apply cleanly to current 1.9 releases.
Comment 21 Kris Shaw 2007-02-23 23:08:15 UTC
I've applied the patch by hand to WebRequest.php and reverted the changes I made to 

I've done some initial testing and so far it looks good. I'll keep testing and make 
sure things work as expected.


Comment 22 Mark Gillespie 2007-02-26 10:27:02 UTC
Hmm, can't get any sense here..  Applied the patch using patch -p1 < WebRequest.php   and it reported it doing it 
correctly (offset 3 lines on MediaWiki 1.9.2)  But when I visit ANY wiki page, I get served any empty page. Backing 
the patch out restores normal operation.  Applying the patch by hand gives the same error.

Now I am using IISLockdown tool, and URLScan.  I have disabled these, and I still can't get any sense out of this, so 
have reverted to the unpatched file..

The only clue, perhaps is in the IIS log:

2007-02-26 09:56:38 - 80 GET /index.php title=Main_Page 200 Mozilla/4.0+
Comment 23 Brion Vibber 2007-03-05 16:40:49 UTC
Empty page probably means a PHP fatal error; make sure you're logging or
displaying errors?

You can usually add these to your LocalSettings.php to force display:

ini_set("display_errors", true);
Comment 24 Mark Gillespie 2007-03-05 17:01:43 UTC
The comment lines in the patch were causing problems..  (C style comments)..  Is this normal?

I have removed the comment lines, and it works...
Comment 25 Brion Vibber 2007-03-05 17:05:20 UTC
Hrm, they should work just fine... maybe confirm it wasn't a missing/extra brace
or something next to them?
Comment 26 Mark Gillespie 2007-03-05 17:36:14 UTC

Using the Win32 port of UnixUtils, to get Patch, seemed to save in some weird character encoding, as I got loads 
of page errors using IIS.  However, as soon as I opened the file up in Notepad, and then saved it, without making 
any changes, everything works again...  This behavior is repeatable....

Anyone, patch seems to be working here now..

Many thanks.
Comment 27 Brion Vibber 2007-03-05 18:58:38 UTC
Good news. :)

Ok, I've gone ahead and committed this on trunk as r20149, on REL1_9 as r20150.
Fix will appear in 1.9.4 if/when it is released, as well as in 1.10.

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