Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4F9A510F.30405@ice-sa.com>
Date: Fri, 27 Apr 2012 09:55:59 +0200
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Long timeout after aborted upload
References: <4F99AE7B.5080609@christopherschultz.net>
In-Reply-To: <4F99AE7B.5080609@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Christopher,

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 : 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org