Has anyone had problems with Perl, IIS, and FastCGI restarting their processes on every POST

Quietly has asked for the wisdom of the Perl Monks concerning the following question:

I think I have found a rather specific bug, and I was wondering if anyone else has encountered this (I'm hoping you have).

I've recently setup an old Perl CGI application to run under FastCGI using a dispatcher script. I've gotten this application to run in both Windows (IIS) and Linux (Apache), and for the most part it runs very stably except for one important exception.

On Windows, using IIS 7 and its FastCGI extension, my FastCGI Perl process dies every time it receives a POST. I've traced the death to FCGI and specifically the libfcgi code that it uses.

In fcgiapp.c, at about line 1717, there is code to close the stream when an empty "FastCGI Packet" is received. After reading the FastCGI Specification's (http://www.fastcgi.com/devkit/doc/fcgi-spec.html) examples at the bottom, I can see that every incoming FastCGI request should end with an empty packet of its own type when it is a FCGI_PARAMS packet or a FCGI_STDIN package. The code in fcgiapp.c seems to close the stream when either an empty FCGI_PARAMS or FCGI_STDIN packet is received, and does not expect any further packets.

Now on Apache, this doesn't seem to cause a problem. On IIS though, when receiving a POST, it sends a FCGI_STDIN packet after an empty FCGI_PARAMS packet. The server, having already seen the empty FCGI_PARAMS packet, seems to close the connection before receiving the FCGI_STDIN packet properly.

I find it hard to believe that a bug like this could have been around so long without someone noticing. That is why I feel this is either a configuration issue, or a problem with my code. If there are others who have experienced this though, I can try to find a common pattern.

Thanks for your time, monks. I hope this discussion ends with a stronger FCGI.pm module, or less buggy version of my code.

The following are links to IIS.net posts about similar problems but with different languages being used:

http://forums.iis.net/t/1170379.aspx
http://forums.iis.net/t/1150498.aspx

Update:I found a solution that works, but unfortunately I don't think it can be fully trusted. I added another action to the FillBuffProc switch statement, and called it PASS_RECORD. Unlike SKIP, it only ignores the current packet, and not the next one as well. I then changed ProcessHeader to return PASS_RECORD when it encountered an empty FCGI_STDIN packet. I'm still analyzing the code to see if there is a cleaner way of doing this using existing logic.

Another update:I got in contact with the maintainer of the FCGI module, and he found a fix for the issue rather quickly. I believe it is being/already committed to FCGI, and the fix (which is in libfcgi) is being sent upstream. Basically, the STDIN stream has to be emptied after each request when using Windows/IIS.

Comment on Has anyone had problems with Perl, IIS, and FastCGI restarting their processes on every POST Select or Download Code

Replies are listed 'Best First'.
Re: Has anyone had problems with Perl, IIS, and FastCGI restarting their processes on every POST by Anonymous Monk on Oct 05, 2010 at 01:36 UTC
Quitely, I've also had this problem and have not yet found a solution (I filed http://forums.iis.net/t/1170379.aspx in August). We switched to Apache from IIS, but the apache mod_fcgid module has other issues (like inserting 1 second delays when it 'waits' for an available process). I looked at the repository for libfcgi for the fix that you mentioned in your last update, but still see a file that hasn't been modified since 2001. Can you please post from where this new source fix is available? Thanks, Steve	[reply]
Re^2: Has anyone had problems with Perl, IIS, and FastCGI restarting their processes on every POST by Quietly (Novice) on Oct 05, 2010 at 21:34 UTC
This is the link to the code change: libfcgi git commit Also, the maintainer told me that a new version of FCGI (the Perl module) will be released soon.	[reply]