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.
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
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.
I have Vista Ultimate SP1 and have tried installing this update but I keep getting the error that “this update does not apply to your system.” I have double and triple checked that I have the right update for my system (Vista SP1 x86). Any pointers?
What is the file version and date modified of this file on your system: %WINDIR%\system32\inetsrv\iisfcgi.dll ?
Yes, I did check that for cgi.dll – these are in C:\Windows\System32\inetsrv\
cgi.dll File Version: 7.0.6001.22229 Last Modified 7/24/2008 8:18PM
iisfcgi.dll File Version: 7.0.6001.22229 Product Version: 7.0.6001.18000 (This is for IIS I think) Last Modified 7/24/2008 8:19 PM
The Knowledge Base article for this update (http://support.microsoft.com/?kbid=954946) suggests converting the last modified time to UTC. I’m MDT, so it’s -7 from UTC.
Sooooo, it looks like I already have the updated cgi.dll and iisfcgi.dll installed then? I guess my problem is different I guess. I’m using pretty permalinks in WordPress on IIS7 (runnign on Vista), and I can’t get to any of the permalinks. I get an “address not found” (firefox) and NOT a typical IIS error page. Strange. Thank you for your quick reply though, I shall continue scouring the internets.
Yes, you already have this update. It has been installed when you installed URL rewrite module.
Have you seen this article (http://learn.iis.net/page.aspx/466/enabling-pretty-permalinks-in-wordpress/) about configuring permalinks for WordPress on IIS7?
Oh, yeah, so that makes sense they were packaged with the URL rewrite module.
I have seen that article, many in fact. Most are from earlier this year, and PHP, MySQL (maybe) and WordPress have all gone through some updates. WordPress in particular went through a major update to 2.7, and I suspect that may be the problem. I will install an older release and see if that helps. Thanks again for the tips.
I am having the same problem on Windows Server 2008 x64. I know I have the right update but it won’t install, giving the same error.
iisfcgi.dll has version 7.0.6002.18005 so I know the update isn’t installed.
I have URL rewrite installed and installed — or thought I installed — it and the fast CGI update via the had used the web platform installer 2.0.
TIA.
Kevin
Kevin, I think you already have the update. The version you have is 7.0.6002.18005. The update version is 7.0.6001.22229. Your version is later.
This feature is broken. 🙁 At first I thought it was never intended to work because there are many articles saying IIS never provides REQUEST_URI. After reading your article, I was inspired to re-test the FastCGI configuration, and I have confirmed it still does not work.
I am trying to do this with IIS 6.0, PHP 5.3.1, and the latest FastCGI file, which appears to be version 1.5. inetsrv\fcgiext.dll says version 7.5.7693.0 (fbl_srv_iis_dev(ksingla).090415-1635).
I might try the IIS dot net website to see what they say. Are there any other resources for this issue?
@miqrogroove: thanks for contacting me. Also the forum on IIS.net is a good place to ask this sort of questions: http://forums.iis.net/1103.aspx.
Can you explain in more details what exacly does not work. The FastCGI extension is supposed to the REQUEST_URI as PHP application expect. Which application does not work with your installation?
Also, note that the fastcgi update described in this blog post only applies to FastCGI module in IIS 7.0. The FastCGI Extension that is used for IIS 5.0 and IIS 5.1 does not need this update because it already sets REQUEST_URI correctly.