Last modified: 2010-05-15 15:28:21 UTC
Using .htaccess to eliminate the index.php from showing up in the pages worked well in 1.3.6 but works badly with 1.3.7. The .htaccess file is: php_flag register_globals 0 # first, enable the processing - Unless your ISP has it enabled # already. That might cause weird errors. RewriteEngine on # Don't rewrite requests for files in MediaWiki subdirectories, # MediaWiki PHP files, HTTP error documents, favicon.ico, or robots.txt RewriteCond %{REQUEST_URI} !^/(stylesheets|images)/ RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html RewriteCond %{REQUEST_URI} !^/favicon.ico RewriteCond %{REQUEST_URI} !^/robots.txt RewriteRule ^(.*)$ index.php/$1 [L,QSA] ~ The relevant bits from the LocalSettings.php file: $wgScriptPath = ""; $wgScript = $wgScriptPath; $wgRedirectScript = "/redirect.php"; ## If using PHP as a CGI module, use the ugly URLs $wgArticlePath = "/$1"; I've had to back out using 1.3.7 on my production wiki because of the performance problems. Yet I hate to leave an unfixed security problem. I've tried looking through the changed code for the problem, but no luck yet.
Please apply the diff at http://mail.wikimedia.org/pipermail/mediawiki-cvs/2004-October/004569.html for the security fix from 1.3.6 -> 1.3.7. Could you be more specific about the problems with 1.3.7? This change certainly shouldn't break rewrite rules, it doesn't touch anything related to that... (that diff is the only change between 1.3.6 and 1.3.7 other than the version number).
If you access the site at http://wiki.itkitchen.info and then the site at http://testwiki.itkitchen.info, you'll notice a very distinctive lag in serving the wiki pages between the 1.3.6 site (wiki.itkitchen.info) and the 1.3.7 site (testwiki.itkitchen.info). When we used index.php, and didn't use the rewrite rules in .htaccess, we didn't get this lag with the new version. Switching back, and there it was again, with no other change in code. When we used the .htaccess and LocalSettings I provided in the comment, we received a very noticable lag in time to serve the pages. (In reply to comment #1) > Please apply the diff at > http://mail.wikimedia.org/pipermail/mediawiki-cvs/2004-October/004569.html for > the security fix from 1.3.6 -> 1.3.7. > > Could you be more specific about the problems with 1.3.7? This change certainly > shouldn't break rewrite rules, it doesn't touch anything related to that... > (that diff is the only change between 1.3.6 and 1.3.7 other than the version > number). (In reply to comment #0) > Using .htaccess to eliminate the index.php from showing up in the pages worked > well in 1.3.6 but works badly with 1.3.7. The .htaccess file is: > > php_flag register_globals 0 > > # first, enable the processing - Unless your ISP has it enabled > # already. That might cause weird errors. > RewriteEngine on > > > # Don't rewrite requests for files in MediaWiki subdirectories, > # MediaWiki PHP files, HTTP error documents, favicon.ico, or robots.txt > RewriteCond %{REQUEST_URI} !^/(stylesheets|images)/ > RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php > RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html > RewriteCond %{REQUEST_URI} !^/favicon.ico > RewriteCond %{REQUEST_URI} !^/robots.txt > > RewriteRule ^(.*)$ index.php/$1 [L,QSA] > ~ > > The relevant bits from the LocalSettings.php file: > > $wgScriptPath = ""; > $wgScript = $wgScriptPath; > $wgRedirectScript = "/redirect.php"; > > ## If using PHP as a CGI module, use the ugly URLs > $wgArticlePath = "/$1"; > > I've had to back out using 1.3.7 on my production wiki because of the > performance problems. Yet I hate to leave an unfixed security problem. I've > tried looking through the changed code for the problem, but no luck yet. (In reply to comment #1) > Please apply the diff at > http://mail.wikimedia.org/pipermail/mediawiki-cvs/2004-October/004569.html for > the security fix from 1.3.6 -> 1.3.7. > > Could you be more specific about the problems with 1.3.7? This change certainly > shouldn't break rewrite rules, it doesn't touch anything related to that... > (that diff is the only change between 1.3.6 and 1.3.7 other than the version > number).
More info: If I change the LocalSettings.php to: $wgScript = "$wgScriptPath/index.php"; $wgArticlePath = "$wgScript/$1"; And get rid of the .htaccess file, the site performance is fine -- no problems. That's the only change. And the only values in the .htaccess file are those shown attached to this bug. I can switch to these if someone wants to see difference.
The problem is that there is some bad code in Title::getLocalUrl() which produces potentially unsafe URLs when smashing everything into the URL root. Due to Internet Explorer security flaws, the raw page loader forbids these and requires a load through the safe canonical URL. The broken Title code produces a different URL, so you get an infinite redirect loop. take this: if ( $wgScript != "" ) { $url = "{$wgScript}?title={$dbkey}&{$query}"; } else { # Top level wiki $url = "/{$dbkey}?{$query}"; } change to: $url = "{$wgScript}?title={$dbkey}&{$query}";
Brion, thanks so much for responding to this. I changed that function to: function getLocalURL( $query = "" ) { global $wgLang, $wgArticlePath, $wgScript; if ( $this->isExternal() ) { return $this->getFullURL(); } $dbkey = wfUrlencode( $this->getPrefixedDBkey() ); if ( $query == "" ) { $url = str_replace( "$1", $dbkey, $wgArticlePath ); } else { if ( $query == "-" ) { $query = ""; } } $url = "{$wgScript}?title={$dbkey}&{$query}"; return $url; } Unfortunately, now I do get an indirection exceeded failure in the wiki. Did I mistake your solution? You can actually see the error take effect now with the wiki. But thanks for helping with this -- it was driving us nuts. Shelley
Looks like one line's out of place. Try this: function getLocalURL( $query = "" ) { global $wgLang, $wgArticlePath, $wgScript; if ( $this->isExternal() ) { return $this->getFullURL(); } $dbkey = wfUrlencode( $this->getPrefixedDBkey() ); if ( $query == "" ) { $url = str_replace( "$1", $dbkey, $wgArticlePath ); } else { if ( $query == "-" ) { $query = ""; } $url = "{$wgScript}?title={$dbkey}&{$query}"; } return $url; }
I see a very similar behavior (even after patching the Title.php as suggested): Main reason for this seems to be that some files are called _very_ often. I'm seeing request as this 21 times: 213.20.141.149 - - [31/Oct/2004:19:19:34 +0100] "GET /?title=Benutzer:Felix/monobook.js&action=raw&ctype=text%2Fjavascript&smaxage=18000&maxage=18000&gen=&oldid=0 HTTP/1.1" 302 26 "http://wiki.felix-schwarz.info/Hauptseite" "Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7) Gecko/20040616"
After reading the bug's description again, I don't think my problem is related. I filed another bug (bug 812) for that. Sorry for bothering.
Yes Felix, even with the bug fix that Brion was so kind to provide (thanks Brion!), the performance is still so slow as to be unusable. However, I believe that we ran into it in 1.3.7. Thanks for pointing out that this is listed in anther bug. I'll be monitoring that one also.
Hello Shelley, Do you still have this trouble with 1.3.9 ?
This is a problem most likely created by a change in RawPage.php, see the IE-related redirect about 2/3 down. comment that out and your site should be fine. I doubt that it makes a difference for IE which filename extensions the url has, but i haven't done a proper check.
(In reply to comment #11) > I doubt that it makes a difference for IE which filename extensions the > url has, but i haven't done a proper check. It certainly makes a difference; that's why the check was added and a security fix release was put out with the change.
In 1.5, non-canonical raw access URLs now return a 403 immediately instead of redirecting, so misconfigured servers will degrade relative gracefully instead of getting into a loop like this. Marking FIXED.
