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