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 Thu, 17 Feb 2011 11:11:20 GMT
On 17.02.2011 11:58, Mark Thomas wrote:
> On 17/02/2011 10:41, Mark Thomas wrote:
>> On 17/02/2011 10:30, Rainer Jung wrote:
>>> On 10.02.2011 18:44, Mark Thomas wrote:
>>>> On 10/02/2011 13:04, Rainer Jung wrote:
>>>>> Servlet 3 standardizes file uploads. It contains the ability to limit
>>>>> 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?
>>>> Yep.
>>> Because of Bill's remark about HTTP compliance and the result of my
>>> browser tests, I think the default behaviour at least for TC before 7
>>> should stay as is.
>> I'd be happy to address the original issue and not swallow the input
>> when a user attempts to upload too large a file.
>> I also need to read through the HTTP spec and see what exactly we are
>> breaking by not reading the entire input stream.
> Just read section 8.2 of RFC 2616. There are a fair number of SHOULDs in
> this section for both the client and the server. The requirement that
> server read all input and not close the connection (on the basis that
> the client will stop sending data when it receives an error status code)
> is "SHOULD NOT" rather than "MUST NOT". Further, the spec explicitly
> allows the server to close the connection for DOS protection.
> Given this, I am leaning even more towards just fixing the original
> issue that the connection is not dropped when the request exceeds the
> upload limit and leaving the rest of the behaviour unchanged.

Just one more data point: with Firefox the browser doesn't read the 
response from the connection if the server closes his side of the 
connection before reading all data. Firefox tries to proceed sending 
until the TCP/IP stack of the server starts responding with reset 
packets. A that time it is to late to read the response.

If you read all data from the connection, then the browser will start 
reading the response and display it, even if the response was alread 
send much earlier.

But nowadays uploads are more often handled by JavaScript or Flash etc. 
solutions running inside the browser which actually do not expect  real 
answer. Closing the connection here results i an error status that the 
calling JavaScript code might be able to handle and reflect in the UI.



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

View raw message