Update for IIS 7.0 FastCGI module
IIS team has recently released an update for IIS 7.0 FastCGI module that fixes compatibility problems with several popular PHP applications. In particular, the update changes the behavior of FastCGI module in the following ways:
- REQUEST_URI server variable set by FastCGI module now includes query string and path info. Previously, lack of the query string in this server variable caused the popular CMS application Drupal to not work with FastCGI on IIS 7.0
- REQUEST_URI server variable now contains the originally requested URL path before any URL rewriting was performed. Prior to this fix, the server variable used to contain a final rewritten URL, which caused problems when using URL rewriting to enable “pretty permalinks” for popular blog engine Wordpress.
Note that above mentioned problems do not exist in IIS 6.0 FastCGI Extension, which always has been setting the REQUEST_URI server variable correctly.
The update is available for download from the following locations:
- Update for Windows Server 2008
- Update for Windows Server 2008 x64 Edition
- Update for Windows Server 2008 for Itanium-based Systems
- Update for Windows Vista SP1
- Update for Windows Vista SP1 for x64 based Systems
Warning: if your PHP application was coded in a way so that it relied on the REQUEST_URI server variable to contain the requested URL without a query string or to contain the final rewritten URL, then installing this update may break your application. Before applying the update, please make sure that your application does not rely on incorrect behavior of FastCGI module.
Acknowledgements: I want to thank IIS team members (Anil Ruia, Won Yoo, Yamini Jagadeesan) for providing this update and Zend Technologies team (Stanislav Malyshev) for validating the changes in FastCGI module.
(3 votes, average: 4 out of 5)
Will these updates be available from Windows Update?
No, these updates will not be offered by Windows Update. Typically, only critical security bug fixes are pushed through the Windows Update.
I am afraid that many users will not be aware of these updates if they are not available from Windows Update.
How about creating a sticky thread on the IIS 7 / FastCGI Forum?
http://forums.iis.net/1104.aspx
Great ! now the wrapper in joomla works !
Franklin, good point about creating sticky thread! I’ve created them here:
http://forums.iis.net/t/1151379.aspx
http://forums.iis.net/t/1151378.aspx
URL Rewrite Module - Go Live release…
Today IIS team has made the Go Live release of URL Rewrite Module for IIS 7.0 available for download. This release contains significant functionality and performance improvements and it is believed to have a quality level suitable for production deploy…
I think I’m running into the latter issue on GoDaddy shared IIS7 hosting, but unfortunately, I can’t be sure. They’re being unresponsive, so I’m hoping someone can validate that my suspicions are correct.
For the latter problem: I’ve debugged my wordpress issue, and it’s come down to this:
$_SERVER['REQUEST_URI'] = ‘/office-monkey/index.php’
when it is expected to be
$_SERVER['REQUEST_URI'] = ‘/index.php’
The client URL I start with is ‘http://www.office-monkey.com/index.php’, but since I’m under shared hosting, the file itself actually resides in ‘/office-monkey/index.php’. I believe this would match the poorly documented issue where the REQUEST_URI is set to the POST-rewrite input, rather than the pre-rewrite input, but I can’t find validation, and don’t have access to a standalone IIS server to validate.
Can anyone help?
It looks like GoDaddy uses some sort of URL rewriting for this. I could think of couple of ways to validate this:
1. Try to access $_SERVER['HTTP_X_ORIGINAL_URL'] or $_SERVER['HTTP_X_REWRITE_URL']. If one of those is set then they use Microsoft URL rewrite or ISAPI_Rewrite respectively. That would mean that they do not have the FastCGI update installed, but you would be able to work it around in wordpress by doing this:
$_SERVER['REQUEST_URI'] = $_SERVER['HTTP_X_ORIGINAL_URL'];
2. If none of those server vars is set then another thing to try is to print out IIS server variable CACHE_URL. Unfortunately, this variable is not accessable from PHP, so you would need to use ASP or ASPX page to print its value. If this server variable contains the http://www.office-monkey.com/default.aspx, then again it proves that the hosting provider does not have the FastCGI update installed. There is no easy workaround for this though, so you would have to ask the hosting provider to install the update.
Thanks for the help, Ruslan.
I created and placed a ASPX page that sets a Label to Request.ServerVariables(”CACHE_URL”). The value that is set is “http://www.office-monkey.com:80:72.167.131.48/Default.aspx”.
From all of this, it sounds like my assumption that my hosting provider needs to install the FastCGI update — is that correct? (I need a clear statement that I can take to the tech support people. :-))
Thank you!
If the Default.aspx is located in /office-monkey/Default.aspx then yes, they need to install the update. After the update is applied FastCGI module will use the URL path from CACHE_URL server variable to set the REQUEST_URI.