httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart Roll" <>
Subject Weird error across connections - keepalive, timeouts, HTTP 413
Date Wed, 21 Nov 2007 20:57:09 GMT
Greetings -


I have encountered a very weird error and I wanted to run it by this
list before I try filing a bug report.


I am running a custom proxy module that receives chunked HTTP requests
using REQUEST_CHUNKED_DECHUNK and then forwards the unchunked payload to
an internal server.


Occasionally a client would hang for about 5 minutes and then return an
HTTP 413 error (HTTP_REQUEST_ENTITY_TOO_LARGE).  Upon investigation it
appears that there is a problem with the persistent connection keepalive
timeouts in Apache.


If I insert a delay in the (Java) client in between opening the response
input stream and reading the last of the response data, and that delay
exceeds the Apache KeepAliveTimeout value then the server closes the
read side of the connection with the client.  The client is, as
expected, able to read the rest of the data correctly.


The next request goes out over the same persistent TCP connection and
immediately gets a TCP RESET (totally expected).  The Sun HTTP client
library automatically opens a new connection and re-issues the request.


Here's the weird part... When the new request comes in on the new
connection, my module gets control normally but when it invokes
ap_get_client_block() it hangs for the configured Timeout value before
returning -1.  Debugging the Apache code a bit, I found that
http_protocol.c:ap_http_filter() receives APR_TIMEUP (70007) from
ap_get_brigade().  This falls through the code and erroneously gets
reported as a 413 error by ap_http_filter().


If I insert the client delay after the client reads the end of the
response, no such error occurs on the next request.


It smells like some bad state carries over from one connection to
another but I don't know how that could happen.


Any ideas from you gurus out there?  I'm starting to get out of my level
of expertise here! ;)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message