[
https://issues.apache.org/jira/browse/FILEUPLOAD-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527250
]
Henri Yandell commented on FILEUPLOAD-145:
------------------------------------------
Looking at the code, I agree with Eric's description above.
The options would seem to be:
1) Remove the eating of the stream from close() (presumably it's there for a
reason).
2) Add a boolean to turn off the eating of the stream and set that when raising
an error in checkLimit.
3) other ideas?
> setFileSizeMax validation is happening after ENTIRE file gets uploaded
> ----------------------------------------------------------------------
>
> Key: FILEUPLOAD-145
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-145
> Project: Commons FileUpload
> Issue Type: Bug
> Affects Versions: 1.2
> Environment: All, however I mainly use Mac OSX
> Reporter: Eric Hermanson
>
> The LimitedInputStream *IS* correctly raising a
> FileUploadBase.FileSizeLimitExceededException in the event of a too-large
> file. 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() (or a bug in close handling after the
> FileSizeLimitExceededException is raised). 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 message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
