Note - this requires fcgibuf.c v1.3 or later.
Note - this requires fcgibuf.c v1.3 or later.

Reorganized FastCgiHandler() and FcgiDoWork() creating two
new functions, ConnectToFcgiApp() and
CloseConnectionToFcgiApp().  Rewrote SendEnvironment(). Minor changes to
FcgiCleanUp() and OS_FreeIpcAddr(). Created a wrapper for
realloc().

ENV Buffer Overflow. Previously, a request environment which
exceeded the output buffer size (minus packet headers and
overhead) would cause the request to fail. This condition
may have occured with very large HTTP GET based form
submission (eg. a long QUERY_STRING). SendEnvironment() now
keeps track of how much of the ENV was sent and FcgiDoWork()
continues to call it until the complete ENV has been sent.

Minimize Connect Time.  Previously, the connection with the
fcgi application would remain until all of the data had been
sent to the client.  The connection is now closed as soon as
comm with the fcgi application is complete.

Removed the potential for a small memory leak when
FastCgiHandler() (functionality that is now in
ConnectToFcgiApp()) failed to obtain a shared read lock
(unlikely occurance) on the deadlock file (dyanamic apps
only).

Improved many of the request handler error log messages.

Improved performance when reading and writing from the fcgi
socket.  The fcgi socket is now non-blocking.  BufferRead()
and BufferWrite() were rewritten (in fcgibuf.c).

Static applications now are subject to the same
appConnTimeout that dynamic apps were (default is 15 sec).
This is consistent with the documentation.  Previously,
connect() for static apps would be left to the OS's
connect() timeout (typically 75 sec, but as much a 3
minutes).  This value is configurable (just as it was for
dynamic apps) via the "FCGIConfig -appConnTimeout <value>"
command.

Removed the ASSERTs around the setting of the signal
handlers in the ProcMgr as suggested by Jeff Vander Clute
<jeff@tripod.com> so we can run with NDEBUG defined.

Also changed the ASSERTs in CgiToClientBuffer() for
header.version and header.type to error messages (with the
request aborted as a SERVER_ERROR).  These conditions are
the result of fcgi app problems, not mod_fastcgi, and should
be handled.  This was the only place I recall seeing/hearing
about ASSERTs popping (so I gave it some consideration).

Added a bit of hack to rename the fcgi processes so they
could be easily identified with ps.  fcgiProcMgr is the
ProcessManager, fcgiKillMgr is the process that sits between
httpd and fcgiProcMgr, and fcgiBlkKill are BlockingKill
processes used to kill off dynamic apps once the deadlock
file becomes available.  The new process names are limited
in length by the original process name, so if apache is
started as "httpd" you get the first five characters of the
new name.

hollow/mod_fastcgi_handler,Gandi/mod_fastcgi_handler,Gandi/mod_fastcgi_handler