Last modified: 2010-05-15 15:28:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2772, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 772 - performance is severely impacted when using new 1.3.7 code with 1.3.6 htaccess file
performance is severely impacted when using new 1.3.7 code with 1.3.6 htacces...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
1.3.x
PC Linux
: Normal critical with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://testwiki.itkitchen.info
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-24 13:20 UTC by Shelley Powers
Modified: 2010-05-15 15:28 UTC (History)
2 users (show)

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


Attachments

Description Shelley Powers 2004-10-24 13:20:55 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.
Comment 1 River Tarnell 2004-10-24 15:07:37 UTC
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).
Comment 2 Shelley Powers 2004-10-24 15:16:24 UTC
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).

Comment 3 Shelley Powers 2004-10-24 15:27:21 UTC
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.
Comment 4 Brion Vibber 2004-10-26 01:58:12 UTC
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}";
Comment 5 Shelley Powers 2004-10-26 02:16:56 UTC
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
Comment 6 Brion Vibber 2004-10-26 02:41:30 UTC
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;
	}
Comment 7 Felix Schwarz 2004-10-31 18:20:19 UTC
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"

Comment 8 Felix Schwarz 2004-10-31 18:34:24 UTC
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.
Comment 9 Shelley Powers 2004-10-31 18:46:31 UTC
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.
Comment 10 Antoine "hashar" Musso (WMF) 2005-01-10 04:40:01 UTC
Hello Shelley,

Do you still have this trouble with 1.3.9 ?
Comment 11 Gabriel Wicke 2005-01-11 19:33:13 UTC
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.
Comment 12 Brion Vibber 2005-01-12 01:15:31 UTC
(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.
Comment 13 Brion Vibber 2005-04-30 00:55:23 UTC
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.

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


Navigation
Links