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