[
https://issues.apache.org/jira/browse/FILEUPLOAD-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639445#action_12639445
]
Martin Cooper commented on FILEUPLOAD-168:
------------------------------------------
The semantic of sizeMax is specifically "the maximum allowed size of a complete
request". That is, if the complete request is larger than sizeMax, regardless
of how many files or fields are being uploaded within it, it is rejected,
because that is exactly what sizeMax is defined to do.
The semantic of fileSizeMax is "the maximum size permitted for a single
uploaded file", which allows the processing of the entire request, but
rejecting any individual files that exceed the specified maximum size for a
single file.
Most of the issues being raised in this report could be resolved by simply
using fileSizeMax instead of sizeMax. Trying to use sizeMax for this does not
make sense, because it does not make sense to allow a request to be processed
that specifically violates the semantic of sizeMax.
If that still doesn't satisfy, the streaming mode was implemented to provide
more flexibility than sizeMax and fileSize Max can do on their own, so if you
need that additional flexibility, the streaming mode was designed for you.
> 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.
