markgillespie wrote:

Also seeing this problem.

IIS5, Windows 2000 server. MediaWiki 1.9.1

Never had this issue before the 1.9.x update.

markgillespie wrote:

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

markgillespie wrote:

II55, ISAPI, Win2k server

markgillespie wrote:

II55, ISAPI, Win2k server

shawkris wrote:

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.

markgillespie wrote:

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

shawkris wrote:

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.

markgillespie wrote:

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.

shawkris wrote:

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

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

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

1. If PHP's memory limit is very low, some operations may fail.
2. 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 ) ) {

1. 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";

1. 1. If using PHP as a CGI module, use the ugly URLs
2. $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";

1. For a detailed description of the following switches see
2. http://meta.wikimedia.org/Enotif and http://meta.wikimedia.org/Eauthent
3. There are many more options for fine tuning available see
4. /includes/DefaultSettings.php
5. 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();

1. To enable image uploads, make sure the 'images' directory
2. is writable, then uncomment this:

$wgEnableUploads = true;
$wgUseImageResize = true;

1. $wgUseImageMagick = true;
2. $wgImageMagickConvertCommand = "/usr/bin/convert";

$wgGroupPermissions['*' ]['upload'] = true;

$wgStrictFileExtensions = false;

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

1. 1. If you have the appropriate support software installed
   2. you can enable inline LaTeX equations:
2. $wgUseTeX = true;

$wgMathPath = "{$wgUploadPath}/math";
$wgMathDirectory = "{$wgUploadDirectory}/math";
$wgTmpDirectory = "{$wgUploadDirectory}/tmp";

$wgLocalInterwiki = $wgSitename;

$wgLanguageCode = "en";

$wgProxyKey = "5231524351e4dbf370b332454d27d1641ca8ba802dd11703dcf16205da0d76f";

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

1. 1. For attaching licensing metadata to pages, and displaying an
   2. appropriate copyright notice / icon. GNU Free Documentation
   3. License and Creative Commons licenses are supported so far.
2. $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:',
);

?>

shawkris wrote:

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.

markgillespie wrote:

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

shawkris wrote:

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
Patch to WebRequest.php which hopefully fixes this

Can you guys test this patch? Should apply cleanly to current 1.9 releases.

Attached:

shawkris wrote:

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.

markgillespie wrote:

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);

markgillespie wrote:

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?

markgillespie wrote:

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.