You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Eric Hermanson (JIRA)" <ji...@apache.org> on 2007/08/31 01:54:30 UTC

[jira] Created: (FILEUPLOAD-145) setFileSizeMax validation is happening after ENTIRE file gets uploaded

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


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.


[jira] Updated: (FILEUPLOAD-145) setFileSizeMax validation is happening after ENTIRE file gets uploaded

Posted by "Jochen Wiedmann (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FILEUPLOAD-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jochen Wiedmann updated FILEUPLOAD-145:
---------------------------------------

    Attachment: FILEUPLOAD-145.patch

Could you please verify, whether the attached patch works?


> 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
>         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.


[jira] Commented: (FILEUPLOAD-145) setFileSizeMax validation is happening after ENTIRE file gets uploaded

Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/FILEUPLOAD-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527250 ] 

Henri Yandell commented on FILEUPLOAD-145:
------------------------------------------

Looking at the code, I agree with Eric's description above.

The options would seem to be:

1) Remove the eating of the stream from close() (presumably it's there for a reason).
2) Add a boolean to turn off the eating of the stream and set that when raising an error in checkLimit.
3) other ideas?

> 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
>
> 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.


[jira] Resolved: (FILEUPLOAD-145) setFileSizeMax validation is happening after ENTIRE file gets uploaded

Posted by "Jochen Wiedmann (JIRA)" <ji...@apache.org>.
     [ 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.


[jira] Updated: (FILEUPLOAD-145) setFileSizeMax validation is happening after ENTIRE file gets uploaded

Posted by "Eric Hermanson (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FILEUPLOAD-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eric Hermanson updated FILEUPLOAD-145:
--------------------------------------


The attached patch does appear to work in that the client (web browser) receives the desired file size max error after fileSizeMax bytes are uploaded (whereas before, the entire (size>fileSizeMax) had to be uploaded before the error was sent).  However, this is still not completely ideal.  It would be desireable for the server to check the file size immediately, before the upload starts, and throw the error in a pre-emptive fashion.  But maybe that information is not available at the fileupload level, and 'fileSizeMax' bytes have to be read in all cases before any error can be thrown?  If so, that's fine.  This patch is one step better than we had before.  Please excuse my ignorance of the inner-workings of the fileupload code.

> 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
>         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.