tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Connection draining when upload to large
Date Fri, 11 Feb 2011 10:44:01 GMT
On 10.02.2011 18:00, Filip Hanik - Dev Lists wrote:
> On 2/10/2011 6:04 AM, Rainer Jung wrote:
>> Servlet 3 standardizes file uploads. It contains the ability to limit
>> on request size, pretty much the same as commons fileupload supported
>> for many years.
>> It seems when this conditions triggers the rest of the request inout
>> stream is still drained at the end of the request. swallowInput is not
>> being set to false.
>> It seems there's still no server-side prevention against huge uploads
>> possible. The upload is not put into memory, but the thread is only
>> freed once the whole request body is read. Shouldn't Tomcat ignore the
>> rest of data and close the connection in this case?
> standard soTimeout (read timeout) should apply. Meaning, if the client
> stops sending data, it should eventually result in an IOException and
> back out the thread.

Right, but this is more about clients sending huge uploads you don't 
want to consume. There should be a clean way of signalling to the 
container, that the rest of the upload should be discarded in the sense 
of "please do not read it and do no longer read from the connection 
(e.g. for Keep-Alive)".

Clients might not react well-behaved to that. E.g. if I change TC code a 
bit and allow it to close the connection instead of draining it before, 
then firefox will still try to upload, finally receive a few resets form 
the server and display an error message - even if the server send out a 
valid HTTP response before closing the reading side of the connection. 
So it won't actually help in transferring an abort message reliably to 
the client, but at least the containr thread would get freed more quickly.



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

View raw message