commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Kitching (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FILEUPLOAD-168) read form field parameters even if maxSize has been exceeded
Date Tue, 14 Oct 2008 14:38:44 GMT

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

Simon Kitching commented on FILEUPLOAD-168:
-------------------------------------------

It seems to me that *something* needs to be done at least.

As the size is being checked even in streaming mode there is no reasonable way to access data
after the file body even in streaming mode. Setting sizeMax to an artificially-high level
then implementing a custom size check while reading from the stream is possible as a workaround,
but is really pretty ugly.

I think the current behaviour should remain the default - AFACT most people will *not* need
the params that follow the file to be available (or there would have been complaints already).
Obviously reading all the file contents from the stream (and just discarding them) is always
inefficient, and for most people not needed. But clearly for some people it is necessary.

I'm not sure about the attached patch. Simply continuing to return data when the size is exceeded
seems pointless as that data is clearly not needed. Instead, how about detecting size overflow
then simply entering a loop to read-and-discard-input until end of that mime part is found,
then throw the exception. People who care could then catch the exception and keep going as
the input stream is correctly positioned.



> read form field parameters even if maxSize has been exceeded
> ------------------------------------------------------------
>
>                 Key: FILEUPLOAD-168
>                 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-168
>             Project: Commons FileUpload
>          Issue Type: Improvement
>         Environment: commons fileupload 1.2.2-SNAPSHOT
>            Reporter: Paul Rivera
>         Attachments: fileupload1.patch, fileupload2.patch
>
>
> Hi!
> This issue is similar to FILEUPLOAD-140.  I can't seem to reopen it so I created a new
one instead.  FILEUPLOAD-140 was marked as resolve by using the streaming API, if I'm not
mistaken.  No change was done.  But I disagree on the resolution of simply using the streaming
API (as detailed in http://commons.apache.org/fileupload/streaming.html).
> First of all, I tried to upload a big file exceeding maxSize with streaming API and got
the SizeLimitExceededException even before ANY parameter has been read.  
> ServletFileUpload.getItemIterator() calls FileUploadBase.getItemIterator() which creates
a new FileItemIteratorImpl().  In the constructor code of FileItemIteratorImpl, it already
checks for the requestSize and throws SizeLimitExceededException if sizeMax is exceeded.
> I'd like to open this discussion again and hope that in the end, we can have either:
>   - form field parameters BEFORE the file parameter will still get read if requestSize
is greater than sizeMax and then terminate once we reach the file
>   - all form field parameters will still get read if requestSize is greater than sizeMax.
 But, we should skip reading the body of the files and proceed to the next 'boundary' so as
not to keep the user waiting, if ever this is possible. (preferred)
> Then, we should also apply the same improvement into PortletFileUpload.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message