[
https://issues.apache.org/jira/browse/FILEUPLOAD-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann resolved FILEUPLOAD-145.
----------------------------------------
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Jochen Wiedmann
A FileSizeLimitExceededException was deferred until the complete file has been
uploaded. Additionally, the FileSizeLimitException is now thrown immediately,
if the attachments headers contain a content-length value, which exceeds the
configured limit. (It is unlikely, that browsers send such a header, but one
can try.)
> 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
> Assignee: Jochen Wiedmann
> Fix For: 1.3
>
> Attachments: FILEUPLOAD-145.patch
>
>
> 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.
