sorry that should be "when the server doesn't pad all the packets to the size of 8"

I am not sure that the reason of problem is padding.
Seems fcgi module doesn't close connection.
Does it use FCGI_KEEP_CONN?
What web server and fcgi module do you use?

I use a purely custom webserver and custom fcgi module, both hand written by me. 

I detected the problem by launching:
valgrind --tool=memcheck -v -v php-cgi -b 42000
Luanch my webserver
Luanch a web browser
Load a php page - Web browser never finish's loading
I press control+c in valgrind, it always outputs it was on:
fcgi_close_connection line 624/recv().

The only reason to "Read 8 bytes" at a time would be if padding were a multiple of 8 bytes, as suggest by:
http://www.fastcgi.com/devkit/doc/fcgi-spec.html

Quote: "We recommend that records be placed on boundaries that are multiples of eight bytes. The fixed-length portion of a FCGI_Record is eight bytes. "

Changing strlen(buf) to 1 is not a potential fix, it is a fix, and it works, I've already tested it.


At worst it will create 1-255 extra loops that do nothing except call recv() while recv still has things to return. (255 if the server pads with 255 bytes extra, which would be a total waste of bandwidth.)

At best it will allow webservers that don't pad to a multiple of 8 bytes to work properly - and not freeze on recv() waiting for data that will never show up.

The server isn't sending _anything_ special to the fcgi client app, it connects(), sends params, sends null on stdin(or post data), returns to the main select() function that returns ALL data from every single connection, waits for FCGI_END_REQUEST or for the socket to be closed, processing and buffering any FCGI_STDOUT data - sending stdout data at end_request. At end request it closes the socket - and prints to the client user whatever's left in the stdout buffer, runs a fast-cgi fifo (If two requests use the same fcgi program it fifo's them), or if FCGI_OVERLOADED or FCGI_CANT_MPX_CONN it will fifo the request.

I've taken the time to create an ethereal dump of a first request - in case it's a problem with my server. it's possible I did something wrong but i don't see it. http://roguestar.dynu.com:5555/fcgidump (load with ethereal fcgidump).

This is a dump of a request to php and back to a www.pastebin.com running on my server. Php is on port 4444, my server is port 46588 in this case.

Your server/fastcgi_module should call shutdown() after sending FastCGI request to PHP (or close() after getting EOF from PHP).

In case of closed connection recv() should be interrupted.

I'm very sorry, There were a two bugs in my server.

the strangest bug was the content-length field being generated as 0.. It's strange this zero content length didn't crop up until switching to 5.1.4 from 5.1.2.. Who knows.. My fault. Fixed. 

The other bug was with the http caching object running on post requests when obviously it shouldn't have. 

Again, very sorry. Thank for your time!