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

Maurizio Cucchiara edited comment on FILEUPLOAD-194 at 3/19/13 8:33 AM:
------------------------------------------------------------------------

Ciao [~simone.tripodi],
the solution you proposed looks really interesting.
At first glance, I'm very confident that this should fix the case of file size 
excess.
At the same time, I'm also pretty sure that your workaround will not work for 
upload size excess: when a multipart request goes beyond the configuration 
parameter, in order to avoid memory issues, an exception is raised and the 
whole request is throwed away.
I'm wondering if there is a way to skip only big content.
What happen if I put the input file on the bottom of the page and the upload 
size exceeds?

                
      was (Author: maurizio.cucchiara):
    Ciao [~simone.tripodi],
the solution you proposed looks really interesting.
At first glance, I'm very confident that this should fix the case of file size 
excess.
At the same time, I'm also pretty sure that your workaround will not work for 
upload size excess and IIUC looks reasonable to me: when a multipart request 
get over the configuration parameter, in order to avoid memory issues, an 
exception is raised.
I'm wondering if there is a way to skip only big content.
What happen if I put the input file on the bottom of the page and the upload 
size exceeds?

                  
> 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

Reply via email to