 (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. 3. 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 4. 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. 6. 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: http://www.MyWebSite.com/cgi-bin/FCGIecho.exe 2. Configure the .INI file. C:\WINDOWS\system32\inetsrv\fcgiext.ini ; This is the configuration file for the FastCGI handler for IIS 6.0. [types] exe=C:\Inetpub\wwwroot\MyWebSite\cgi-bin\FCGITest.exe [C:\Inetpub\wwwroot\MyWebSite\cgi-bin\FCGITest.exe] QueueLength=999 MaxInstances=20 InstanceMaxRequests=500 IdleTimeout=30 ActivityTimeout=30 RequestTimeout=30 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: http://www.MyWebSite.com/cgi-bin/FCGITest.exe http://www.MyWebSite.com/cgi-bin/FCGIecho.exe http://www.MyWebSite.com/cgi-bin/FCGIcount.exe 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: FCGITest.exa FCGIecho.exb FCGIcount.exc --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.
[types] exa=C:\Inetpub\wwwroot\MyWebSite\cgi-bin\FCGITest.exa exb=C:\Inetpub\wwwroot\MyWebSite\cgi-bin\FCGIecho.exb exc=C:\Inetpub\wwwroot\MyWebSite\cgi-bin\FCGIcounter.exc [C:\Inetpub\wwwroot\MyWebSite\cgi-bin\FCGITest.exa] QueueLength=999 MaxInstances=20 InstanceMaxRequests=5 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 [C:\Inetpub\wwwroot\MyWebSite\cgi-bin\FCGIecho.exb] QueueLength=999 MaxInstances=20 InstanceMaxRequests=500 IdleTimeout=20 ActivityTimeout=20 RequestTimeout=60 SignalBeforeTerminateSeconds = 2 [C:\Inetpub\wwwroot\MyWebSite\cgi-bin\FCGIcounter.exc] QueueLength=999 MaxInstances=20 InstanceMaxRequests=500 IdleTimeout=20 ActivityTimeout=20 RequestTimeout=60 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: http://www.MyWebSite.com/cgi-bin/FCGIecho.exb 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 test.abc, 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 --------- . . 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 --------- |