Wikimedia Bugzilla is closed!

Also seeing this problem.

IIS5, Windows 2000 server.  MediaWiki 1.9.1

Never had this issue before the 1.9.x update.

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...

I'll see if I can get my Windows/IIS test VM up and try this out.

Testing IIS 6, Windows 2k3, PHP 5.2.0 set up as cgi/fcgi. No problems.

Will try reconfiguring for ISAPI...

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...

II55, ISAPI, Win2k server

II55, ISAPI, Win2k server

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?

First, the exact error message displayed.

Second, the output of this script:

<?php
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:
http://localhost/wiki/loop.php?title=Something&action=edit&section=1

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:

REQUEST_URI: 
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.

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

Hello,

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.

-----------

Regards,

Kris.

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.

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.

Hello,

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.

Regards,

Kris.

<?php

# 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 = "helpdesk@xxxxx.co.uk";
$wgPasswordSender	= "helpdesk@xxxxx.co.uk";

## For a detailed description of the following switches see
## http://meta.wikimedia.org/Enotif and http://meta.wikimedia.org/Eauthent
## 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(
	'http://',
	'https://',
	'ftp://',
	'irc://',
	'gopher://',
	'telnet://', // Well if we're going to support the above.. -ævar
	'nntp://', // @bug 3808 RFC 1738
	'worldwind://',
	'mailto:',
	'news:',
	'file:',
	'mms:',
);

?>

Hi,
One thing I've noticed is that the '#' symbol isn't in the URL variables, eg:

http://localhost/loop.php?title=Sand_Pit#H1

(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.

Regards,

Kris.

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

Thanks.

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...

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:

http://wiki.xxx.xxx.xxx/index.php?title=Sand_Pit#Test
http://wiki.xxx.xxx.xxx/index.php?title=Sand_Pit#Test

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

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

Regards,

Kris.

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
REQUEST_URI but not QUERY_STRING)

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
URL...

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.

Hello,
I've applied the patch by hand to WebRequest.php and reverted the changes I made to 
Wiki.php.

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

Thanks,

Kris.

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 195.213.115.75 - 195.213.112.56 80 GET /index.php title=Main_Page 200 Mozilla/4.0+
(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+InfoPath.1;+.NET+CLR+3.0.04506.30)

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);
error_reporting(E_ALL);

The comment lines in the patch were causing problems..  (C style comments)..  Is this normal?

I have removed the comment lines, and it works...

Hrm, they should work just fine... maybe confirm it wasn't a missing/extra brace
or something next to them?

Strangeness...

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.

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.