RTM of FastCGI for IIS6

Posted: Nov 12, 2007  1 comments  

Average Rating

IIS News Item

Share this Post

The IIS team is happy to announce that the RTM version of the FastCGI for IIS is now available for download at http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1521.  FastCGI support on IIS6, which is a free download, opens up the Windows Server 2003 platform for hosting PHP and other FastCGI-compliant application frameworks with substantially improved performance and stability. In FastCGI, we are reusing CGI processes for multiple requests to PHP applications so that we can have comparable hosting of PHP hosting on Windows to Linux. As part of this effort, we have been validating the popular PHP applications on Windows and publishing walkthroughs that give step by step instructions on how to setup and install the most popular PHP apps on top of FastCGI and Windows Server.

This release does not support in-place upgrade for the GoLive version of FastCGI. If you have already installed the GoLive version of FastCGI, you will have to uninstall the GoLive FastCGI first, and then install the RTM version.

The EULA for the final release is limited to IIS6 which runs on Windows Server 2003.

This release version contains the following updates since our GoLive release on 9/24/2007, including:

New features!

  • Changes to fcgiext.ini are now picked up automatically without requiring a restart of IIS or the worker process.  We've also changed fcgiconfig.js so that it no longer does a recycle or restart when it writes configuration.
  • FastCGI's rapid fail protection threshhold is now configurable.  You can add a RapidFailsPerMinute property to the fcgiext.ini file for each FastCGI application.  This setting will specifiy the number of FastCGI process failures allowed in a single minute before the FastCGI handler takes it off line.  The default value is 10.
  • The '-syncini' switch has been added to fcgiconfig.js to synchronize IIS script mappings to match the types defined in fcgiext.ini.  This is useful in cases where the FastCGI handler has been uninstalled and reinstalled, or when manual changes have been made to fcgiext.ini that are not reflected in the IIS script mappings.

Updates to the runtime to fix the follow issues:

  • FastCGI logs 200 no matter what status is set by script
  • Content-Length inserted in response entity when script uses “\n\n” to terminate headers
  • Fix race condition that could cause A/V under load
  • Headers terminated with ‘\n’ cause “Error data is invalid” 500 error
  • Responses with empty headers caused the FastCGI handler to fail.
  • Machines running 64bit IIS with Enable32BitAppOnWin64 set would look for fcgiext.ini from the \windows\syswow64\inetsrv directory instead of the \windows\system32\inetsrv directory.
  • There were some cases where the status code logged by a FastCGI request would be different that what the client actually received.
  • We've improved stability under load.

Improved setup:

  • Upgrade support for future upgrades of IIS6. Note that if you upgrade your server to Windows Server 2008, you will need to manually switch to the FastCGI available in IIS7 if you would like to use it.
  • Provide service restart warning on uninstall that is visible when using Add/Remove Programs
  • Updated versioning support

Starting with our first Technical Preview in October 2006, we have been impressed and invigorated by the IIS community’s participation in helping us deliver the best extension for support for FastCGI-compliance application frameworks like PHP in IIS. We also would like to thank Zend Technologies for their continued partnership in making PHP work well on Windows. We wanted to thank you, the IIS community, for your support and encourage you to keep the dialogue going through our FastCGI handler forum.



I found a possiable problem:

I used $_SERVER['PATH_INFO'] in my php code, and must get Chinese charactors passed, but I found that the encoding of this variable is GB2312,  It should be UTF-8, and I also tested on Apache both windows and Centos, It works well as UTF-8, I think it may be fixed.

Nov 15 2007 by lonestone

Submit a Comment

  • Plain text is accepted.
  • URLs starting with http:// are converted to links.