tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Connection draining when upload to large
Date Thu, 17 Feb 2011 10:58:10 GMT
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 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?
>>> 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.


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

View raw message