You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Keith Wannamaker <Ke...@Wannamaker.org> on 2001/01/22 05:44:15 UTC

[PATCH] [BUG] mod_jserv/Tomcat race condition

Hi, two separate issues.

First, I believe this is a renegate ap_kill_timeout;
the timeout is 'refreshed' almost immediately afterwards.
http://www.apache.org/~keith/patch.txt

Second, I have been debugging the following scenario
with mod_jserv and Tomcat:  
Browser sends a large request body.  Servlet deduces that
the content-length is too large, decides to disallow the
request, and returns a brief response without reading
the body.  ie, uploading a file that is too big.

mod_jserv alternates between sending 8k blocks and
listening for any Tomcat response.  Tomcat reads off
the headers, and the Servlet writes its response.  
Unfortunately, after mod_jserv sends about 24k, 
the send() blocks.  The servlet writes its response;
Tomcat flushes and closes the socket.  That causes
mod_jserv to unblock with a connection aborted error,
which fails with 500.  The race is, if the servlet
manages to get the response off before mod_jserv 
blocks, it works as expected.

At first glance it seems the solution is for the 
servlet to read the body anyway.  But this doesn't
seem to be in the spirit of rfc 1867, which clearly
intends for the server to be able to abort the upload
if it deems the file too large.

Any ideas on another solution?  Maybe lingering the
socket greater than ap_write's timeout?

Keith