Configure IIS6

(Also see tips for IIS Hardening.)

  1. FCGIEXT.DLL is registered as an ISAPI extension.
  2. When request for FastCGI-
mapped resource is made to IIS, then IIS calls FCGIEXT.DLL.
FCGIEXT.DLL reads the configuration from FCGIEXT.INI. One configuration property is  
     the actual FastCGI application that needs to be called. That application needs to 
     support the FastCGI protocol. In your example, that's FastCGITest.exe
FCGIEXT.DLL creates a new instance of FastCGITest.exe and passes request data to it via 
     stdin by using the FastCGI protocol. Typically the data is passed via named pipe.
  5. FastCGITest.exe processes the data, generates the response, and sends it back to 
FCGIEXT.DLL on stdout via named pipe.
FCGIEXT.DLL passes the response data back to IIS, which sends it to the client.

IIS 7 works almost the same way except that the DLL is called IIBFCGI.DLL, it is registered as a 
handler, and its configuration is stored in the applicaitonHost.config file.

Setting up FastCGI on
Windows Server 2003 IIS 6.0
using default (unmodified) ACLs/permissions

1. Setup FastCGI
Open the IIS Manager from the Start menu or right click on MyComputer and select Manage.

This explanation might not be exhaustive, but it identifies the key steps.

First, enable the FastCGI handler.

Enable Scripts in your website's cgi-bin directory:

Map the .EXE extension to FCGIEXT.EXE so requests can be routed according to the settings in the .INI file.

Finally, copy the LIBFCGI2.DLL and your FastCGI application (FCGIecho.exe) to the cgi-bin directory.

The URL would then be:

2. Configure the .INI file.

FastCGI mapping configuration is done in the FCGIEXT.INI file found at:

; This is the configuration file for the FastCGI handler for IIS 6.0.


SignalBeforeTerminateSeconds = 5

This will map all HTTP requests with a URL ending in .EXE to FCGITest.exe

3. Configuring Multiple FastCGI Applications
This is where some creativity is needed because IIS maps all HTTP requests for a given extension (.EXE in this case) to the one FastCGI application specified
in the .INI file above. 

For example, in regular CGI:

All would all be routed to the corresponding different CGI applications. If you have .EXE assigned to FastCGI, then they would all be routed to a single FastCGI application!

FastCGI is written to send all these requests to a single .EXE (specified in the .INI file) because PHP.EXE is designed to receive all HTTP Requests. PHP then calls the corresponding script. Since PHP is a huge force in  FastCGI deployment, we just have to work around this behavior.

So what do you do if you need several FastCGI applications to handle different tasks?

 The fastest way to get this to happen is to use a different extension for each FastCGI application.  For example:
--and so on

Notice I have chosen not to use .EXE in any of these mappings. This is so that I can continue to use .EXE for regular CGI applications. (I still have about 10 small regular CGI applications that do small tasks that I have not gotten around to rewriting yet.)
I view FastCGI as an addition to CGI for the moment and thus want to add it to the server without disturbing regular CGI operations. To do this I must avoid using the .EXE extension  and pick a different extension for each FastCGI application.

Each extension must be entered in the mapping:

 ; This is the configuration file for multiple FastCGI applications.


IdleTimeout=10     ; Time application can remain idle
ActivityTimeout=5  ; Time available for application to communicate with IIS
RequestTimeout=6   ; Time available for application to complete Request
SignalBeforeTerminateSeconds = 2

SignalBeforeTerminateSeconds = 2

SignalBeforeTerminateSeconds = 2


Windows IIS can execute a binary that does not end in .EXE, so all you need to do is compile your application as .EXE and then edit the extension on the server.

The URL would then be:

The FastCGI team suggests using handlers/scriptmaps, which can be configured based on filename and not just extension. You specify different script processors for different file names in the IIS configuration for this to work.

The only thing you need to be careful of is the order of handlers/scriptmaps. First, the handler/scriptmap which matches the current request will be picked by IIS. So if *.abc appears before, the *.abc handler will be picked.

When I implement this I will add my notes here.

SignalBeforeTerminateSeconds Timing:

In the case of FCGITest.exa specified above, suppose a request is received and processed. If no further requests come in, the application will sit in memory waiting for 10 seconds; then the SIGTERM event is fired. If the application is still running 2 seconds later, it will be terminated.

To Illustrate, the debug output for this application would look like:

-------- DEBUG BEGIN ---------
Version= 2.093
05-03-2009 16:55:00 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Init



05-03-2009 16:55:10 - IIS SIGTERM Received

05-03-2009 16:55:12 - Application terminated (this line is not actually generated)

-------- DEBUG END ---------

See an Example Log.