As I mentioned, the LimitedInputStream *IS* correctly raising the
exception. However, the exception isn't getting *processed* until
AFTER all of the data is read. This is because of what appears to be
a bug in MultipartStream.ItemInputStream.close(). After the
LimitedInputStream correctly raises the file size exception, someone
attempts to close the MultipartStream, but the close() method
repeatedly calls 'makeAvailable()' which ends up reading the rest of
the file upload data anyways, REGARDLESS of the size limit exception
being raised. This is clearly a bug, is it not?
Please do correct me if I'm wrong.
- Eric
On Aug 30, 2007, at 2:13 AM, Jochen Wiedmann wrote:
On 8/30/07, Eric Hermanson <[EMAIL PROTECTED]> wrote:
setFileSizeMax is apparently intended to prevent the file upload if
the file about to be uploaded is larger than a given size. However,
the exception does not get processed until AFTER the entire file is
uploaded to the server (thereby defeating the purpose of the limit).
That's not the case. If you are setting this property, then the file
items input stream is wrapped by an instance of LimitedInputStream.
That instance raises the exception as soon as more than fileSizeMax
bytes are returned to the caller. It may certainly look so, if the
uploaded file is, for example, 10.5 MB and the limit is 10MB. Apart
from that, it is quite possible that the exception is ignored by the
browser and the browser continues to shuffle data to the server. But
that's nothing we can control.
I admit, that an additional improvement could be made: We might check,
if the file items headers (as opposed to the request headers) contain
a content-length entry, which exceeds the limit. However, I admit that
this would help, because I've seen few cases where the item does
contain a content-length header. Patches welcome, though.
I went into the debugger and noticed that
MultipartStream.ItemInputStream.close()
is calling
MultipartStream.ItemInputStream.makeAvailable()
and the call to InputStream.read() in that method is actually what's
causing the entirety of the oversized file upload data to be
incorrectly read.
This may be the case, if you haven't read all the data before invoking
the close() method.
Jochen
--
"Besides, manipulating elections is under penalty of law, resulting in
a preventative effect against manipulating elections.
The german government justifying the use of electronic voting machines
and obviously believing that we don't need a police, because all
illegal actions are forbidden.
http://dip.bundestag.de/btd/16/051/1605194.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
