Search results matching tag 'FastCGI'

IIS Documentation Updates on PHP.NET

Anonymous — Tue, 10 Nov 2009 19:18:44 GMT

PHP.NET web site is known for its well written and very detailed documentation. The excellent content together with tons of user contributed notes has made the PHP.NET the primary place for getting the help on all PHP related questions.

However there was one thing in the PHP docs that was still not up-to-date. The Windows and IIS-specific installation and configuration sections did not cover the latest changes in Windows, such as IIS 7 and FastCGI. Now I am glad to let everyone know that this part of the PHP documentation is also being updated!

Check out the first batch of updates:

The content is still being updated and there are plans to add more instructions, such as how to install PHP on Windows with PHP Installer, how to easily upgrade to PHP 5.3, how to run multiple PHP versions side by side, etc. If you have any suggestions on the updated content or if you have any additional instructions that you think will be useful, please submit user notes on PHP.NET.

Feature additions and bug fixes coming up in WinCache

ksingla — Mon, 05 Oct 2009 21:35:00 GMT

We are seeing huge momentum behind adoption of WinCache. In the month of September, WinCache v1 Beta was downloaded more than 13,000 times making it one of the most downloaded IIS extensions in the first month following its release. Many happy customers chose to run it on their production servers despite its beta tag. We got very encouraging feedback from the beta release and we are pushing hard for our next release. Our next release date is approaching fast and I wanted to give an update on new features and bug fixes. If your favorite feature was missing in the beta and is also not in the list below, please email me or post on the forums so that we can consider it for future releases of WinCache.

Bug Fixes

1. We fixed a bug due to which same file was getting included twice even when include_once/require_once was used. Some PHP applications didn’t work due to this bug.
2. Few customers reported crashes when running WinCache on their test servers. This was because file cache component didn’t cache zero-size files properly.
3. One customer didn’t see enough performance improvement when using cakephp. This was because of a bug in opcode cache which caused us to recompile the code every time.
4. One bug caused opcode cache’s total hit count to be negative after first request. Also hit count of different file entries in file cache was one more than expected. Both of these bugs are fixed.
5. WinCache caches compile time errors and warnings generated by PHP engine. We fixed a bug due to which warning/errors caching sometimes caused next request to return 500.

New features

1. We are adding an API “bool wincache_refresh_if_changed()” to force a file change check on a file next time it is used from cache. This is useful if you change a file in PHP code and you want next request to load the file from disk again. You can pass blank or null which tells API to refresh all the files in the cache. An array of absolute/relative paths as argument will make WinCache only refresh these file entries. Please note that file will be reloaded from disk only if a file change is detected. This API enforces a file change check and not necessarily removal of cached entry.
2. In the next release, users will be able to disable file change checks completely by setting value of wincache.chkinterval to 0. When file change checks are disabled, changed file will be reloaded only when wincache_refresh_if_changed is called or IIS application pool is recycled. Cached files will still get removed by scavenger when the file is not used for a long time causing wincache to load the file again.
3. Another feature getting added is to enable administrators choose a list of websites for which wincache.ocenabled property is opposite of global setting affecting all the websites. This was requested by a hoster who wanted a safe and quick mechanism to turn-off WinCache for websites which run into some problems.
4. By default, caching in WinCache will be disabled when PHP is running in CLI (command line) mode. Setting wincache.enablecli to 1 will turn on caching in CLI mode.
5. We will be exposing total_cache_uptime property from wincache_fcache_fileinfo() and wincache_ocache_fileinfo() which will give total cache uptime in seconds.
6. On popular demand, we are including a PHP script (wincache.php) in WinCache setup which users can use to see cache statistics.

If you haven’t had a chance to test your PHP application with WinCache yet, download and try it out today. We are looking forward to your feature requests, bugs and general feedback to guide us for future releases of WinCache.

Update: WinCache RC release is available now.

Thanks,
Kanwal

Migrating FastCGI configuration from IIS 5.1/6.0 to IIS 7.0/7.5

ksingla — Fri, 25 Sep 2009 01:18:00 GMT

Problem
As you know FastCGI functionality on IIS 5.1 and IIS 6.0 is provided by FastCGI ISAPI extension which is available as an independent download. On IIS 7.0 and beyond, FastCGI functionality is provided by IIS FastCGI module which comes with the operating system. These components use different configuration stores to store the settings that affect their behavior. FastCGI ISAPI uses an INI file named fcgiext.ini as its configuration store whereas FastCGI module keeps configuration in applicationHost.config in xml format with rest of IIS configuration. Before, migrating from IIS6 to IIS7 involved migrating fcgiext.ini configuration to FastCGI module manually as there was no automated way to do that. MSDeploy only had functionality to migrate metabase configuration but because FastCGI ISAPI configuration is kept separately in an INI file, that wasn’t possible.

Solution
MSDeploy v1 RTW which is released today include a new provider named fcgiextConfig to automate task of migrating FastCGI ISAPI INI configuration to FastCGI module section. FcgiextConfig provider accepts a path which can be “APPHOST” or ”INI”. When path “APPHOST” is specified, configuration from system.webServer/fastCgi section in applicationHost.config is read. Path “APPHOST” should only be used on systems running FastCGI module (i.e. IIS7 and beyond). When path “INI” is specified, this provider reads the configuration from file “%windir%\system32\inetsrv\fcgiext.ini” and produce xml which looks like FastCGI module configuration. Once INI settings are mapped to produce the xml, msdeploy engine can compare configuration of FastCGI ISAPI with FastCGI module and make changes to FastCGI module configuration as required. Again, path “INI” can only be used on a machine which is running FastCGI ISAPI.

Examples
Dump command to dump INI settings looks like following.
        msdeploy –verb:dump –source:fcgiExtConfig=ini –xml
        msdeploy –verb:dump –source:fcgiExtConfig=apphost –xml

Sync command to move INI settings to FastCGI module section is following.
        msdeploy –verb:sync –source:fcgiExtConfig=ini –dest:fcgiExtConfig=apphost -whatif

Details
Here is how INI settings are mapped to system.webServer/fastCgi settings. For each entry “<extension>:<optionalsiteid>=<sectionname>” under [Types] section of fcgiext.ini, we read the settings under section [<sectionname>]. If optional site id is present, we look for an entry for the same extension but without site id. If an entry is found, we use configuration under this entry as base set of settings for the site specific entry. So if “php=basephp” and “php:1=site1” entries are present in INI, settings under section [basephp] provide base values and then settings under section [site1] override base settings to generate configuration for “php:1” process pool. If a property is not present in the INI file, we assume the default value as assumed by FastCGI ISAPI extension. A FastCGI process pool entry is created for each INI entry with a valid ExePath. Various INI file settings are mapped to a FastCGI process pool as below.

fcgiext.ini configuration setting	system.webServer/fastCgi/application property
ExePath	fullPath
Arguments	arguments
QueueLength	queueLength
MaxInstances	maxInstances
IdleTimeout	idleTimeout
ActivityTimeout	activityTimeout
RequestTimeout	requestTimeout
InstanceMaxRequests	instanceMaxRequests
FlushNamedPipe	flushNamedPipe
Protocol	protocol
RapidFailsPerMinute	rapidFailsPerMinute
EnvironmentVars	environmentVariables
ResponseBufferLimit	Ignored
IgnoreExistingFiles	Ignored
IgnoreDirectories	Ignored
UnhealthyOnQueueFull	Ignored

If the source version is FastCGI ISAPI 1.5, some additional properties get picked and mapped as below.

StderrMode	stderrMode
MonitorChangesTo	MonitorChangesTo
SignalBeforeTerminateSeconds	signalBeforeTerminateSeconds

If FastCGI ISAPI version on source and FastCGI module version on destination are not compatible, fcgiextConfig provider will block the migration. Note that fcgiextConfig provider doesn’t take care of migrating the relevant IIS ScriptMaps. You can migrate ScriptMaps using a separate msdeploy migrate operation.

Hope this helps.
Kanwal

Windows Cache Extension for PHP and CPU usage

Anonymous — Thu, 03 Sep 2009 00:17:49 GMT

The FastCGI module in IIS has a configuration setting maxInstances, which controls the number of concurrently running php-cgi.exe processes that IIS creates to process PHP requests. To achieve optimal performance, it is recommended to fine tune this setting for your specific environment starting with 8-10 instances per CPU core (e.g. maxInstances=32 for quad-core CPU).

The Windows Cache Extension for PHP can be used to improve performance of PHP applications running on Windows operating systems. The extension caches the compiled PHP opcode in the shared memory, which helps to avoid re-doing of such CPU intensive operations as parsing and compiling of the PHP source code. This means that when Windows Cache Extension for PHP is enabled, less CPU cycles are required for a web server to process PHP requests. Because of that, the previously configured value for the FastCGI maxInstances setting may not be adequate to load the server’s CPU completely and it may be necessary to increase the value further.

To increase the maxInstances value on IIS 7 run this command from an elevated command line prompt:

appcmd.exe set config  -section:system.webServer/fastCgi /[fullPath='C:\PHP\php-cgi.exe',arguments=''].maxInstances:"32"  /commit:apphost

Note: replace the fullPath with the path to php-cgi.exe on your server.

Alternatively you can just edit the <fastCGI> section the applicationHost.config file located at C:\Windows\System32\inetsrv\config\ folder:

<fastCgi>
  <application fullPath="C:\PHP\php-cgi.exe" maxInstances="32">
  <!-- Some other settings may go here-->
  </application>
</fastCgi>

To increate the maxInstances value on IIS 5.1 and IIS 6.0 run this command:

>cscript C:\windows\system32\inetsrv\fcgiconfig.js -set -section:"PHP" –MaxInstances:32

Note: replace the section name if necessary.

Alternatively you can edit the fcgiext.ini file located at C:\Windows\System32\inetsrv\ folder:

[PHP]
ExePath=C:\PHP\php-cgi.exe
;some other settings may go here
MaxInstances=32

When you measure the performance of the Windows Cache Extension for PHP, make sure to monitor the CPU usage. If you see that CPU is not fully utilized try increasing the FastCGI maxInstances setting and you may be able to get better performance results.

Windows Cache Extension 1.0 for PHP – Beta

Anonymous — Tue, 01 Sep 2009 17:10:37 GMT

Today IIS team has released the beta of the Windows Cache Extension 1.0 for PHP. The Windows Cache Extension for PHP is a PHP accelerator, that is used to increase the speed of PHP applications running on the Windows operating systems. Any PHP application can take advantage of the functionality provided by the Windows Cache Extension for PHP without any code modifications. All that is required is that the extension is enabled and loaded by the PHP engine.

Install the Windows Cache Extension 1.0 for PHP – Beta

or, download:

Windows Cache Extension 1.0 for PHP 5.2 – Beta

Windows Cache Extension 1.0 for PHP 5.3 – Beta

Follow the instructions at “Using Windows Cache Extension for PHP” to install, enable and configure the extension.

Note:

The extension can only be used with non-thread-safe builds of PHP
The extension can only be used when IIS is configured to run PHP via FastCGI
The Windows Cache Extension 1.0 for PHP 5.3 can only be used with the x86 VC9 build of PHP 5.3.

Benefits and Features

The extension includes three caches that can be enabled or disabled independently of each other:

PHP opcode cache – PHP is a script processing engine, which reads an input stream of data that contains text and/or PHP instructions and produces another stream of data, most commonly in the HTML format. This means that on a web server the PHP engine reads, parses, compiles and executes a PHP script each time that it is requested by a Web client. The reading, parsing and compilation operations put additional load on the web server’s CPU and file system and thus affect the overall performance of a PHP web application. The PHP bytecode (opcode) cache is used to store the compiled script bytecode in shared memory so that it can be re-used by PHP engine for subsequent executions of the same script.
File cache – Even with the PHP bytecode cache enabled, the PHP engine has to accesses the script files on a file system. When PHP scripts are stored on a remote UNC file share, the file operations introduce a significant performance overhead. The Windows Cache Extension for PHP includes a file cache that is used to store the content of the PHP script files in shared memory, which reduces the amount of file system operations performed by PHP engine.
Relative file path cache – PHP scripts very often include or operate with files by using relative file paths. Every relative file path has to be converted to an absolute file path by the PHP engine. When a PHP application uses many PHP files and accesses them by relative paths, the operation of resolving relative paths to absolute paths may negatively impact the application’s performance. The Windows Cache Extension for PHP provides a Relative File Path cache, which is used to store the mappings between relative and absolute file paths, thereby reducing the number of relative path resolutions that the PHP engine has to perform.

More information

Use the Windows Cache Extension for PHP Forum to ask questions, report bugs and provide feature suggestions

Per-site PHP configuration with PHP 5.3 and IIS

Anonymous — Sat, 11 Jul 2009 07:05:27 GMT

About a year ago I wrote an article about how to enable per-site PHP configuration on IIS with FastCGI. The instructions in that article required some non-trivial manipulations of IIS and FastCGI configuration settings. At that time it was one of the primary options for enabling per site php.ini support (other option was to use the htscanner extension for PHP). Now, with PHP 5.3 final release available, it is much simpler to implement the same configuration because PHP 5.3 has built-in support for per-directory INI settings and for user-defined INI files. This post describes how to use these features of PHP 5.3 with IIS to enable per-site and per-directory PHP configuration.

Assume that you have two web sites in IIS – website1.com and website2.com. The root directory for website1.com is at C:\Inetpub\website1.com\ and the root directory for website2.com is C:\Inetpub\website2.com\ . Let’s say that the PHP application at website1.com does some heavy database activity and hence requires longer script execution time, which in PHP is controlled by max_execution_time setting. Also, let’s say that the PHP application at website2.com is a photo album, where visitors may upload very large image files. Because of that it requires bigger maximum allowed file upload size, which is controlled by the php.ini setting upload_max_filesize.

To enable the above described scenario on IIS, first you need to install PHP 5.3 and configure IIS to work with it. The easiest way is to use PHP Installer available at the community PHP site. Make sure to use the installer for VC9 non-thread-safe build of PHP 5.3 and choose the “IIS FastCGI” option during the installation. Alternatively, you can follow the instructions described in Using FastCGI to Host PHP Applications on IIS 7.0 and create the FastCGI handler/script mapping on the server level, so that it applies to all web sites on the server.

Now you have two options:

Define the per-site PHP settings in the main php.ini file
Allow web application owners to define those settings in user defined INI files.

For option #1 open the main php.ini file (if you used PHP installer, then this file will most probably be located at C:\Program Files\PHP\ folder. If you installed from a ZIP archive then the file will be at the same directory where php-cgi.exe file is). Add the following at the end of the file:

[PATH=C:/inetpub/website1.com/]
max_execution_time = 300

[PATH=C:/inetpub/website2.com/]
upload_max_filesize = 12M

Save the php.ini file and then recycle the application pools for these web sites for the php.ini changes to take effect.

After that you can use phpinfo() or ini_get(‘max_execution_time’) to check that these settings overwrite the default ones:

The output shows that the local value of max_execution_time setting (in the second column) is 300, while the master value, or default, is 30.

Alternatively, if you want to allow web application owners to control PHP settings themselves, you can enable user defined PHP configuration. To do that, add the following setting to main php.ini file:

user_ini.filename = .user.ini

This setting specifies the name to be used for user-specific ini files. Setting this to empty value disables the user defined PHP configuration.

After that create a file called .user.ini in C:\inetpub\website1.com\ folder and place and put this line into it:

max_execution_time = 300

Also, put this line into the file .user.ini in C:\inetpub\website2.com\ folder:

upload_max_filesize = 12M

Note that if your main php.ini file has [PATH] sections that point to the root folders of these sites, then you need to remove those sections; otherwise user defined settings will not take effect.

Again, you can use phpinfo() or ini_get() functions to check that the user defined settings overwrite the default ones:

One more thing that you need to be aware of when you enable the user defined ini files is that the settings in those files are cached by PHP engine to avoid re-reading those files for every request. This means that if the user makes a change to .user.ini file then that change may not take effect right away. Instead it may take effect after the cache time-to-live has expired. The cache TTL value is controlled by the php.ini setting user_ini.cache_ttl, which is set to 300 seconds (5 minutes) by default.

Getting both FastCGI module and AppPool CPULimit to work

ksingla — Thu, 02 Jul 2009 23:29:00 GMT

FastCGI module available in IIS 7.0 did not work when CPULimit for the application pool was enabled. This was because when CPULimit feature was enabled WAS uses job objects to track CPU usage of worker processes. WAS keeps a job object for each application pool and all worker processes which belong to that application pool are made part of that job object. FastCGI module uses job objects to make sure that there are no orphan child processes left when worker process goes away. Note that FastCGI requires a per process job object while WAS requires a per application pool job object. For this reason, it was not possible to make WAS take care of killing FastCGI child processes when worker process dies. Because a process can only be part of one job object on windows and also the fact that a child process becomes part of the job object if parent process is already part of existing job object, FastCGI module was unable to make child processes part of another job object when CPULimit was turned on and used to fail with error “Unable to place a FastCGI process in a JobObject. Try disabling the Application Pool CPU Limit feature”.

Customers who used CPULimit feature complained about limitation. We recommended customers to use WSRM (windows system resource manager) but some wanted to continue using CPULimit functionality. Due to requests from these customers we have fixed this issue in Windows 7 (Win2K8 R2) and also released a QFE for Win2K8 release. In the fix, WAS lets FastCGI make its child processes part of other job object. Also FastCGI module keeps track of CPU usage of its child processes and periodically report CPU usage by children back to WAS which then adds that to the application pool CPU usage count.

You can read more about this here and here. QFE can be downloaded from here.

Hope this helps.

Kanwal

FastCGI Extension 1.5 for IIS 6.0 and IIS 5.1 – RC

Anonymous — Wed, 24 Jun 2009 22:38:07 GMT

Today IIS team has released the FastCGI Extension 1.5 for IIS 6.0 and IIS 5.1 – Release Candidate. This version is based on FastCGI Extension 1.0 and it adds several important improvements and features. The release is believed to have a quality level suitable for production deployments.

Install the Release Candidate of FastCGI Extension 1.5 for IIS 6.0 and IIS 5.1

or, download:

FastCGI Extension 1.5 for IIS 6.0 and IIS 5.1 – RC (x86)

FastCGI Extension 1.5 for IIS 6.0 and IIS 5.1 – RC (x64)

Upgrade from FastCGI Extension 1.0 and 1.5 Beta releases

If you already have installed FastCGI Extension v1.0 or FastCGI Extesnion v1.5 Beta, then the installation package will upgrade it to version 1.5 – RC. All the related IIS configuration and settings in fcgiext.ini file will be preserved during upgrade. Note that during upgrade from v1.0 the comments in fcgiext.ini will not be updated and will not mention new configuration settings. However the new settings can still be used after upgrade.

New Features

The FastCGI Extension 1.5 includes these new features:

Monitor changes to a file. The extension can be configured to listen for file change notifications on a specific file and when that file changes, the extension will recycle FastCGI processes for the process pool. This feature can be used to recycle PHP processes when changes to php.ini file occur.
Real-time tuning of MaxInstances setting. This MaxInstances setting dictates the maximum number of FastCGI processes which can be launched for each application pool. If it is set to 0 then FastCGI extension will automatically adjust the number of instances up or down every few seconds based on the system load and number of requests waiting in the queue.
STDERR stream handling. There are several options of how the extension can handle text sent by FastCGI application on STDERR. The extension can send the error data as a failure response to the HTTP client or it can ignore the error and send whatever was received on STDOUT as a response with 200 status code.
Sending a termination signal to FastCGI processes. The extension can be configured to send a termination signal to FastCGI process before terminating it. This enables FastCGI processes to do a clean shutdown before getting killed.
_FCGI_X_PIPE_ environment variable. This variable is set by FastCGI extension and it contains the name of the named pipe that is used for communication between the extension and FastCGI process.
Relaxed enforcement of response headers syntax. The FastCGI extension has less strict enforcements for the correctness of the response headers.

Changes since Beta release

The following changes and bug fixes has been made to the extension since the beta release:

The fix for a bug in how the semicolons are handled when reading configuration settings from fcgiconfig.ini file. Now, if you need to specify a semicolon inside of a configuration setting you can escape it with “/” (forward slash) symbol. This bug was reported on FastCGI forum.
If the SignalBeforeTerminateSeconds setting is more than 0, then FastCGI extension does not lock the file, specified in MonitorChangesTo setting, while processing the change notification and recycling the FastCGI processes.

More information

Refer to the following resources for more information

Also, be sure to visit the FastCGI Handler forum on IIS.NET if you have run into any problems when using the extension or have questions or suggestions.

Tip #71: Did you know... there are several new configuration settings available in FastCGI Extension 1.5 Beta

Anonymous — Mon, 01 Jun 2009 19:54:06 GMT

Following are the new configuration settings available in FastCGI 1.5 Extension Beta:

MonitorChangesTo - This property specifies path to a file, changes to which will trigger a recycle of FastCGI executables running for this FastCGI process pool. If value of this property is blank, file change monitoring is disabled. Path to file can be absolute or relative to folder in which FastCGI process (as specified by ExePath) is present. If not specified, default value is blank.

StderrMode - Specifies how content received on stderr is handled. The allowed values are:

'ReturnStderrIn500' - FastCGI Extension will set response status code to 500 and send whatever was received on stderr stream as a response. This is the same behavior as in FastCGI Extension v1.0.

'ReturnGeneric500' - The Extension will set the response status code to 500, but will return a generic 500 response.

'IgnoreAndReturn200' - Data on stderr is completely ignored and FastCGI Extension will send what was received on stdout as a response with status code 200.

'TerminateProcess' - The Extension will terminate FastCGI process as soon as it returns anything on stderr. A generic response with 500 status code will be send to HTTP client.

If setting not specified, the default value is 'ReturnStderrIn500'.

MaxInstances - This setting dictates maximum number of FastCGI processes which can be launched for each application pool which is also equal to maximum number of requests which can be processed simultaneously as one process handle only one request at a time. This setting existed before in FastCGI Extension v1.0. However, with FastCGI Extension 1.5 it can be set to 0, which will turn on automatic adjustment of the maximum number of instances. When it is set to 0, FastCGI Extension will constantly analyze current CPU load and memory availability and based on that will increase or decrease the number of FastCGI process instances running at the same time.

SignalBeforeTerminateSeconds - Specifies the number of seconds to elapse after setting shutdown event and before calling TerminateProcess thereby forcibly terminating the process. Default value is 0 which means event is not set and FastCGI processes can be terminated abruptly at any time. If this value is greater than 0, FastCGI process will create an event which is inherited by the child process. Handle value of this event is set as environment variable _FCGI_SHUTDOWN_EVENT_. The name of the named pipe, used to communicate with the process is stored in environment variables _FCGI_X_PIPE_.

ActivityTimeout - This is the number of seconds that the FastCGI handler waits for I/O activity from a process before it is terminated. This setting existed before in FastCGI Extension 1.0 but in v1.5 its default value has been increased from 30 seconds to 70 seconds.

The new FastCGI Extension 1.5 Beta can be downloaded at:

FastCGI Extension 1.5 for IIS 6.0 and IIS 5.1 (x86)

FastCGI Extension 1.5 for IIS 6.0 and IIS 5.1 (x64)

Don Raman
SDET, IIS Team

FastCGI ISAPI 1.5 Beta for WinXP and Win2K3

ksingla — Tue, 21 Apr 2009 05:39:00 GMT

IIS team today released FastCGI ISAPI 1.5 Beta for WinXP and Win2K3 which has some very nice additions to existing FastCGI ISAPI functionality. Following additions have been made to FastCGI ISAPI 1.0.

1. Few features we added to FastCGI module in IIS 7.5 have been added to FastCGI ISAPI 1.5 as well. These include MonitorChangesTo, StderrMode and Real-time tuning. Read more about these here.

2. Few customers complained about IIS terminating the FastCGI processes abruptly (on running into IdleTimeout, InstanceMax etc) without giving them a chance to run cleanup code in the FastCGI application. In FastCGI ISAPI 1.5, we have added ability to get a signal from IIS whenever we are about to terminate a child process. To enable this, you need to set SignalBeforeTerminateSeconds property in fcgiext.ini to greater than 0. When this functionality is enabled, IIS will create an inheritable event and pass its handle value to child process as value of _FCGI_SHUTDOWN_EVENT_ environment variable. If FastCGI ISAPI ever encounters a situation (like worker process shutting down, fcgiext.ini changed, file being monitored changed etc) and is required to terminate the child process, it will first signal this event and wait for a maximum of SignalBeforeTerminateSeconds for process to terminate on its own. On detecting event being signaled, child processes can terminate themselves cleanly. If child process are still alive after the wait period, IIS will forcibly terminate them.

3. Name of the named pipe through which communication with FastCGI process is taking place is communicated as value of _FCGI_X_PIPE_ environment variable.

4. Many customers faced trouble with FastCGI 1.0 because they accidently added some invalid configuration to fcgiext.ini and couldn’t decipher the cryptic error message they got from FastCGI ISAPI. In this release, if we see an invalid property present or invalid value of an enum type property, we exactly tell you what’s wrong in fcgiext.ini and where the error is.

5. FastCGI 1.0 had very strict checking on validity of response headers. We got bunch of reports from customers who complained about this difference of behavior compared to other web servers. In this release, we have removed these checks. If we find an invalid response header, we silently drop it from the response. This behavior matches behavior of other web servers.

6. Customers easily ran into ActivityTimeout especially while running install.php code of popular PHP applications. So we have changed default value of ActivityTimeout from 30 seconds to 70 seconds.

Below are the download links to FastCGI ISAPI 1.5 Beta. If you are using WebPI, FastCGI 1.5 is available under “what’s new” section. You can upgrade from FastCGI ISAPI 1.0 to FastCGI ISAPI 1.5 Beta or do a fresh install today. If you any feedback or trouble using FastCGI ISAPI 1.5, please report it on forums.

X86 – http://download.microsoft.com/download/C/7/8/C783108B-2FA7-4245-835C-E0B887A394D1/fcgisetup32.msi
X64 – http://download.microsoft.com/download/5/9/6/596CF5CB-9581-48A5-9205-4D9E3B4FB9BD/fcgisetup64.msi

We also worked with Mike from Coast Research who fixed many issues in libfcgi.dll. Also he made changes to libfcgi.dll to make it handle SIGTERM properly using SignalBeforeTerminate functionality we added to FastCGI. Mike kindly released updated libfcgi (called libfcgi2.dll) so that others can now write a FastCGI application with much less pain. You can download libfcgi2.dll from here. Mike has published samples and documentation on how to use libfcgi2.dll on www.coastrd.com. Complete white paper on additions to libfcgi2.dll can be found here.

Thanks,

Kanwal