Modification to mod_fastcgi

Hello,

during implementation of a project we met a problem with mod_fastcgi.
We are using SuSE Linux Professional 9.3 but the problem can
be reproduced on a SLES9.

We were using a dynamic FastCGI process.

The following happens: If the answer to a request to the server
has more than 8192 Bytes and less then about 16000 Bytes
of payload, the HTTP header is not counted, the request will
fail with an idle timeout. But the FCGI server has delivered
the complete response to the apache server in time.

We looked into the problem and found that the apache server
needs two times to read and fill the serverInputBuffer.
On the first read it takes the HTTP header
and some part of the payload which ist not enough to fill the
clientOutputBuffer completely. So, when returning from
fcgi_protocol_dequeue, the HTTP header is analysed and
the first part of the payload is moved to the clientOutputBuffer
but not sent to the client. Then the second part of the
message of the FCGI server is read, up to 8192 Bytes.
It contains all the rest of the payload and the end of request
protocol blocks. In the routine fcgi_protocol_dequeue
this part of the message is evaluated. The routine
cannot copy all of the remaining payload to the clientOutputBuffer
because that buffer is still filled with the payload component of the
first message. So that number of Bytes is copied, that fits
into the clientOutputBuffer and the routine returns to socket_io.
The data in the clientOutputBuffer is then sent to the
client and the buffer is emptied.
But then the routine socket_io calls again ap_select and tries
to read more data from the FCGI server. But there is no data
left to read and so we get an idle timeout.

We do not use the libfastcgi but a special C++ framework because
we needed some features which libfastcgi did not provide.
This framework does not close the socket the apache web server
after the end of the request as libfastcgi seems to do.
If we modify that framework so that it closes the connection,
everything seems to work fine because the ap_select returns
without a timeout, fcgi_protocol_dequeue is called again,
finds the end of request blocks and finishes the request.
That seems not to match the FCGI specification which allows
more than one request per connection. The framework expects
the apache server to close the connection and does its close
procedure when the hangup on the input socket is encountered.

So we propose a quite primitive modification to mod_fastcgi:
We added a routine to fcgi_protocol.c which tries to figure out
if the end of request protocol blocks are completely contained
in the data read from the FCGI server.
We added a block to the routine socket_io before the call to
ap_select. This block calls the newly added routine. If this
call finds the end of request protocol blocks, ap_select is
called with a very small timeout value and no timeout error
is delivered if ap_select returns with a timeout for this call.

This modification makes mod_fastcgi working for us.

We would ask you to check if you can include our modification
to the mod_fastcgi main development line.


Best Regards


<http://www.arcor.de/ums/ums_ordner.jsp?ordnername=Gesendet&mailid=1&aktion=oeffnen&umid=1&sortieren=datums>

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/