Bug #82068 for FCGI: FCGI breaks with IIS 7.5

Good day, I have found that FCGI using IIS 7.5 can get in to a state that brings down your website. When you do many post requests in a short period of time IIS at some point will not send the TYPE 5 terminating packet (ZERO content length). IIS continues to send the FCGI packets for new requests that comes in but, FCGI is stuck in a state where it ignores any new packets cause it is waiting for the TYPE 5 terminating packet for Request ID N. This leaves your web service in a state that you constantly get an 500 internal server error. Only when IIS restart the process (specified by the IIS settings for FCGI) will the service be back up and running. This is an actual IIS issue cause they are at fault for not sending the TYPE 5 terminating packet at some point in time, but FCGI is left in a very bad state. I saw that PHP users complains about intermittent 500 internal server errors when using IIS. I believe that the PHP FCGI interface probably drops the incomplete packet but continue processing new requests coming in. Can FCGI maybe handle this more appropriately instead of discarding all new incoming packets. Please find attached (iistype5.txt) a TCP log between IIS and Perl FCGI showing the missing TYPE 5 terminating packet from IIS and that Perl FCGI rejects every request afterwards. 1) Load the file with Wireshark. Set the filter options to "tcp.port == 57696" 2) Entry no 1972 shows FCGI TYPE 1 packet for Request ID 0x91 3) Entry no 1974 shows FCGI TYPE 4 packet (PARAMS) for Request ID 0x91 4) Entry no 1977 shows FCGI TYPE 4 terminating packet 5) Entry no 1979 shows FCGI TYPE 5 (DATA_IN) packet 6) Entry no 1981 shows FCGI TYPE 5 terminating packet 7) Entry no 1983 shows FCGI TYPE 6 data out packet. In this same TCP packet is the TYPE 6 terminating packet and TYPE 3 end request packet. 8) This was the last successfull packet. Note that the TYPE 1 packets are all RESPONSE role packets meaning that TYPE 6 packets can be sent before teh TYPE 5 terminating packet. If the log file is inspected you will note that most of the time the TYPE 6 packet is sent before the TYPE 5 terminating packet is received. 1) Entry no 1985 shows the FCGI TYPE 1 packet for request ID 0x92 2) Entry no 1987 shows the FCGI TYPE 4 packet 3) Entry no 1990 shows the FCGI TYPE 4 terminating packet. 4) Entry no 1992 shows the FCGI TYPE 5 packet. 5) Entry no 1994 shows the FCGI TYPE 6 packet, with its terminating packet and the TYPE 3 end request packet. 6) Entry no 1996 shows the FCGI TYPE 1 packet for Request ID 0x93. NOTE: IIS Never sent the TYPE 5 terminating packet for Reuqest Id 0x92. 7) Entry no 1998 shows the TYPE 3 end request packet for Request Id 0x93. From this point Perl FCGI is ending all requests cause the Request Id does not match 0x92. -- *Johannes Wilke* Striata - Software Engineer Office: +27(81)308-1837 Email: *johannes.wilke@striata.com* <mailto:johannes.wilke@striata.com> Striata on: *Twitter* <https://twitter.com/striata> | *LinkedIn* <http://www.linkedin.com/company/striata> | *Facebook* <https://www.facebook.com/striata.innovation> | *striata.com* <http://www.striata.com> *Latest blog post: http://striata.com/blog* <http://striata.com/blog?signature> This email and all contents are subject to the following disclaimer: *http://www.striata.com/_disclaimer*