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