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