river wrote:

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

shelleyp wrote:

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

1. first, enable the processing - Unless your ISP has it enabled
2. already. That might cause weird errors.

RewriteEngine on

1. Don't rewrite requests for files in MediaWiki subdirectories,
2. 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).

shelleyp wrote:

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}";

shelleyp wrote:

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;

}

felix.schwarz wrote:

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"

felix.schwarz wrote:

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.

shelleyp wrote:

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.