Last modified: 2007-01-16 01:50:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3000 - REQUEST_URI is not set under IIS
REQUEST_URI is not set under IIS
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
PC Windows XP
: Normal normal with 3 votes (vote)
: ---
Assigned To: Brion Vibber
http://www.mendozamission.com/wiki/in...
:
: 3054 5404 8574 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-30 13:23 UTC by Nathan Given
Modified: 2007-01-16 01:50 UTC (History)
4 users (show)

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


Attachments
Untested patch against r19274 (3.56 KB, patch)
2007-01-15 03:47 UTC, Brion Vibber
Details

Description Nathan Given 2005-07-30 13:23:20 UTC
I receive this error when I navigate to various pages in my own MediaWiki:

Notice:  Undefined index:  REQUEST_URI in includes\WebRequest.php on line 276

(I think it only occurs when I view Special pages).

I just uploaded the wiki last night to a windows machine (I have no control over
the machine... it is managed by my hosting provider).  I think they are running
IIS with php installed as a CGI (however, I am not positive).

I have found a solution to this error.  The solution I found comes from here:

http://tinyurl.com/dvgas

It is this:

Replace the following function (in includes/WebRequest.php, line 271:

/**
 * Return the path portion of the request URI.
 * @return string
 */
function getRequestURL() {
	return $_SERVER['REQUEST_URI'];
}

With this one:

/**
 * Return the path portion of the request URI.
 * @return string
 */
function getRequestURL() {
	// Work around REQUEST_URI bug under W2K/IIS/CGI/PHP
	if (!isset($_SERVER['REQUEST_URI']) and isset($_SERVER['SCRIPT_NAME'])) {
		$_SERVER['REQUEST_URI'] = $_SERVER['SCRIPT_NAME'];
		if (isset($_SERVER['QUERY_STRING']) and !empty($_SERVER['QUERY_STRING']))
			$_SERVER['REQUEST_URI'] .= '?' . $_SERVER['QUERY_STRING'];
	} 

	return $_SERVER['REQUEST_URI'];
}

This is becaue in that IIS is not setting REQUEST_URI in the environment for PHP
under CGI mode.
Comment 1 Rob Church 2006-01-04 10:41:23 UTC
*** Bug 3054 has been marked as a duplicate of this bug. ***
Comment 2 Bartosz Milewski 2006-01-05 20:53:20 UTC
I tried this solution in a similar environment. It helped with some bugs, but 
our wiki site is still not fully functional--I cannot edit pages. When I save 
may edits, I am redirected to the page that shows "this is only a preview".

If it helps, here's the link http://www.relisoft.com/wiki (I turned off 
anonymous editing because of spambots, so you have to create an account).
Comment 3 Brion Vibber 2006-01-05 21:04:15 UTC
Editing preview problems are due to PHP's session configuration; usually on Windows this is because a 
default php.ini file ships with a bogus session.save_path value. Make sure this is set to a direction which 
exists and can be written to.
Comment 4 Bartosz Milewski 2006-01-08 23:31:43 UTC
Another thing, after making the above change, the html output contains links 
that are formatted differently. For instance, I get:
<a href="/wiki/index.php/ReliCodia:How_does_one_edit_a_page" 
title="ReliCodia:How does one edit a page">how to edit a page</a> 
instead of:
<a href="/wiki/index.php?title=ReliCodia:How_does_one_edit_a_page" 
title="ReliCodia:How does one edit a page">how to edit a page</a>
The question mark was replaced by a slash. I'm not sure if it's relevant, 
since the links still work.
Comment 5 Nathan Given 2006-01-09 02:08:34 UTC
Bartosz,

I'm not a PHP guru by any means, but I would do some debugging with the
following line of my bugfix:

$_SERVER['REQUEST_URI'] .= '?' . $_SERVER['QUERY_STRING'];

I say this because it shouldn't be replacing the ? with /.  Perhaps the request
isn't making it to this line of the bugfix because it it is contained within an
if block:

if (isset($_SERVER['QUERY_STRING']) and !empty($_SERVER['QUERY_STRING']))

Maybe IIS is messing something up?  Perhaps the isset() function is returning
false when it shouldn't?  I would do some testing and see if your requests are
causing this if statement to be true.

This is only speculation.
Comment 6 Sarith Sircar 2006-01-09 14:12:52 UTC
I get another error when configuring Wiki with IIS. This error is with regard to 
the LDAP plugin - 

Notice: Undefined variable: servers in 
C:\Wiki\mediawiki\includes\LdapAuthentication.php on line 87

Perhaps this is an IIS configuration problem? Or could it be a bug in the plugin? 
I don't get this error with Apache server. So I'm guessing this is something to do 
with IIS?

Your inputs would be helpful.
Comment 7 Sarith Sircar 2006-01-11 07:17:52 UTC
(In reply to comment #6)
> I get another error when configuring Wiki with IIS. This error is with regard 
to the LDAP plugin - Notice: Undefined variable: servers in 
C:\Wiki\mediawiki\includes\LdapAuthentication.php on line 87Perhaps this is an 
IIS configuration problem? Or could it be a bug in the plugin? I don't get this 
error with Apache server. So I'm guessing this is something to do with IIS?Your 
inputs would be helpful.

Solved:
Replace - 

function authenticate( $username, $password ) {
                global $wgLDAPDomainNames, $wgLDAPServerNames, 
$wgLDAPSearchStrings;
                global $wgLDAPUseSSL;

With - 

function authenticate( $username, $password ) {
                global $wgLDAPDomainNames, $wgLDAPServerNames, 
$wgLDAPSearchStrings;
                global $wgLDAPUseSSL, $servers;
Comment 8 Sasha G 2006-03-06 13:28:21 UTC
REQUEST_URI is used in several places in the code, instead of calling
WebRequest::getRequestURL.

This should probably be fixed as part of this bugfix.

Sasha.
Comment 9 Nathan Given 2006-03-06 17:58:57 UTC
I was revamping my site and I accidentally deleted my wiki so the URL (
http://www.mendozamission.com/wiki/index.php?title=Special:Whatlinkshere&target=Main_Page
) doesn't work anymore.  Sorry
Comment 10 Brion Vibber 2006-03-31 02:43:31 UTC
*** Bug 5404 has been marked as a duplicate of this bug. ***
Comment 11 Jordan Young 2006-10-03 18:08:46 UTC
This bug still seems to exist for 1.7 under IIS.  The code in
includes/WebRequest.php seems to have changed a little.  Here's what I changed
it to, and it seems to work:

<pre>
	/**
	 * Return the path portion of the request URI.
	 * @return string
	 */
	function getRequestURL() {
/* MediaWiki Version 1.7 workaround for
http://bugzilla.wikimedia.org/show_bug.cgi?id=3000
Original code:
		$base = $_SERVER['REQUEST_URI'];
Replaced with:
*/
	if (!isset($_SERVER['REQUEST_URI']) and isset($_SERVER['SCRIPT_NAME'])) {
		$base = $_SERVER['SCRIPT_NAME'];
		if (isset($_SERVER['QUERY_STRING']) and !empty($_SERVER['QUERY_STRING']))
			$base .= '?' . $_SERVER['QUERY_STRING'];
	}
/* End new code */
		if( $base{0} == '/' ) {
			return $base;
		} else {
			// We may get paths with a host prepended; strip it.
			return preg_replace( '!^[^:]+://[^/]+/!', '/', $base );
		}
	}
</pre>
Comment 12 Mike Bogle 2007-01-15 02:40:46 UTC
*** Bug 8574 has been marked as a duplicate of this bug. ***
Comment 13 Brion Vibber 2007-01-15 03:47:47 UTC
Created attachment 3072 [details]
Untested patch against r19274

I can't test this on IIS myself until I figure out how to get my XP Pro
installation out of a VirtualPC gulag; would appreciate feedback before I
commit this. :)
Comment 14 Nathan Given 2007-01-15 03:59:49 UTC
Brion Vibber:

That patch looks awesome!  (I just got done reading it).  However, like you, I don't have a currrent MediaWiki setup to test this out on.

However, you can get windows 2003 server on a virtual pc virtual hard disk from microsoft: http://www.microsoft.com/windowsserver2003/evaluation/trial/default.mspx  (30-day 
evaluation).

If you are willing to install Win 2003 server in a VM yourself, you can download a 120-day evaluation ISO: http://www.microsoft.com/windowsserver2003/evaluation/trial/
viewtrialoptions.mspx#EQH

I hope this helps! 
--
Nathan
Comment 15 Brion Vibber 2007-01-15 04:02:03 UTC
Aha, now an ISO I should be able to get running in Parallels... thanks!
Comment 16 Brion Vibber 2007-01-16 01:50:23 UTC
Ok, confirmed the problem on IIS 6 under Win2k3, with PHP 5.2.0 running as CGI.
(It seems fine running as an ISAPI module.)

Confirmed that the patch appears to fix problems; install, a bit of surfing
around, recentchanges, editing seem to work. No visible notices anymore with
error reporting and display_errors tweaked up, and the special page tab includes
the expected URL variables.

Applied on trunk in r19321, and in REL1_9 as r19322 since it looks not too
disruptive.
Will be in 1.9.1 point release.

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


Navigation
Links