tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Long timeout after aborted upload
Date Fri, 27 Apr 2012 07:55:59 GMT

Christopher Schultz wrote:
> Since Tomcat appears to be idle pretty much right away, the issue has
> to be either mod_jk or httpd, or the browser itself. Is there anything
> I can do at the web server level to sever the connection ASAP? Or is
> this just a stubborn browser that refuses to give up until the last
> byte has been sent?
You have to think of it this way : there is a lot of machinery and piping and intermediate

holding tanks between the browser which is uploading the file, and ultimately your Tomcat

webapp.  So even when your webapp whistles "stop!", there will be a significant delay 
before that filters down to the browser.
And the main issue is that, while it is uploading the data, the browser isn't reading 
anything from the webserver.  There is no "out of band" mechanism in HTTP for the 
webserver to tell the browser to stop in the middle of an upload (which is just "sending a

HTTP request").  The only way is for the webserver to shut down the connection on which 
the browser is writing, which would cause the browser to experience a "Connection reset" 
error (which doesn't look very nice).
Other than that, the browser will only look for a response, when it has finished sending 
its request (which sounds logical, when you think about it).
Even to achieve the closing of the upload connection, you would need a mechanism for your

webapp to be able to tell the closest possible "node" to the browser, to drop that 
connection.  There is no such standard mechanism. (And between the browser and your 
webserver, there can be proxies etc.).

Sending a response to the browser including a "Connection: close" header, just tells the 
browser that it will not be able to send *its next request* on the same HTTP/TCP 
connection, and that it will have to build a new connection.  But it doesn't impact the 
current request/response cycle.

This all being said, this section of the HTTP RFC provides some interesting clues :

If this thing of stopping the browser waisting its time is really important in your case,

then on the base of the above, one could imagine a solution, based on for example a 
specialised browser "applet" which would send the file-to-upload using a separate HTTP 
request including an "Expect" header (see section 8.2.3), then waiting for the server to 
answer with a "100 Continue" response before sending the body.
(And hoping that the webserver handles this properly).
It seems worth a try, but it also seems fairly complicated to do right.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message