commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maurizio Cucchiara (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FILEUPLOAD-194) conceptual error throwing FileUploadException when upload size or file size exeeds limits
Date Tue, 19 Mar 2013 09:09:15 GMT

    [ https://issues.apache.org/jira/browse/FILEUPLOAD-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13606181#comment-13606181
] 

Maurizio Cucchiara commented on FILEUPLOAD-194:
-----------------------------------------------

{quote}
I haven't got why the whole request would thrown away, in the case of upload size excess,
can you please provide me a sample?
{quote}
I think that is a security limit, in order to avoid an Out of Memory Error, in case a multipart
request fills the whole memory capacity.
FileUpload reads the value from the request header, before reading the multipart content (which
could be a time consuming task), in case, for instance, a malicious user fills your memory
with an ad-hoc request.

I'm going to provide some small junit tests and yes, there is a way to run the test in struts,
but I think it could be easier to focus on fileupload code.

                
> conceptual error throwing FileUploadException when upload size or file size exeeds limits
> -----------------------------------------------------------------------------------------
>
>                 Key: FILEUPLOAD-194
>                 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-194
>             Project: Commons FileUpload
>          Issue Type: Bug
>    Affects Versions: 1.2.2
>            Reporter: Hanspeter D├╝nnenberger
>         Attachments: my-changes.patch
>
>
> When any size limits exceed, immediately a FileUploadBase.SizeLimitExceededException
or FileUploadBase.FileSizeLimitExceededException is thrown and parsing of the multipart request
terminates without providing request parameters for further processing.
> This basically makes it impossible for any web application to handle size limit exceeded
cases gracefully. 
> My proposal is that request parsing should always complete to deliver the request parameters.
Size limit exceeded cases/exceptions might be collected for later retrieval, FileSizeLimitExeededException
should be mapped to the FileItem to allow some validation on the FileItem on application level.
This would allow to mark upload input fields as erronous if the uploaded file was too big.

> Actually I made a patch for that (see attachment). With this patch, commons-fileupload
always completes request parsing in case of size limit exceedings and only after complete
parsing will throw an exception if one was detected. Using FileUploadBase.setThrowUploadException(false)
no exceptions will be thrown (except more critical ones like invalid stream format).
> After request processing the collected FileUploadExceptions might be retrieved using
FileUploadBase.getFileUploadExceptions().
> The patch shows the concept, but further improvement might be necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message