Mailing-List: contact issues-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@struts.apache.org
Date: Mon, 11 Nov 2013 14:26:19 +0000 (UTC)
From: "Chris Cranford (JIRA)" <jira@apache.org>
To: issues@struts.apache.org
Message-ID: <JIRA.12453239.1236477313832.51555.1384179979067@arcas>
In-Reply-To: <JIRA.12453239.1236477313832@arcas>
References: <JIRA.12453239.1236477313832@arcas>
Subject: [jira] [Commented] (WW-3025) Parameters get lost when file upload
 over max size allowed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Chris Cranford commented on WW-3025:
------------------------------------

I am working on a new multipart parser for Struts2 I am calling JakartaStreamMultiPartRequest.  

This multi-part parser behaves identical to the existing Jakarta multi-part parser except that it uses the Commons FileUpload Streaming API and rather than delegating maximum request size check to the File Upload API, it's done internally to avoid the existing problem of the Upload API breaking the loop iteration and parameters being lost.

I should have it polished and posted as an attachment within the next 24-48 hours.

> Parameters get lost when file upload over max size allowed
> ----------------------------------------------------------
>
>                 Key: WW-3025
>                 URL: https://issues.apache.org/jira/browse/WW-3025
>             Project: Struts 2
>          Issue Type: Improvement
>          Components: Core Interceptors
>    Affects Versions: 2.1.6
>         Environment: All
>            Reporter: Tom Nguyen
>             Fix For: Future
>
>
> When the uploaded file gets rejected because it's content, size, or because of a general problem an Exception is thrown by the MultiPartRequest class. Exceptions are: InvalidContentTypeException, UnknownSizeException, SizeLimitExceededException, and FileUploadException. This can lead to serious problems within the application because the other parameters from the upload form get lost. Happening in a profile page for example means that the user data is lost this can lead to a security Exception. In other case this usually just involves a OGNL-Exception. Meaning your field data like personal file name is lost. Workaround found in http://henning.kropponline.de/index.php/2009/01/18/struts2-fileuploadbase-exception/, but the the still keep uploading to server, not secured.


--
This message was sent by Atlassian JIRA
(v6.1#6144)