[ 
https://issues.apache.org/jira/browse/WW-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5413:
------------------------------
    Fix Version/s: 6.5.0

> Multipart misbehavior with commons-io 2.16.0 and 2.16.1
> -------------------------------------------------------
>
>                 Key: WW-5413
>                 URL: https://issues.apache.org/jira/browse/WW-5413
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 6.3.0
>            Reporter: Riccardo Proserpio
>            Priority: Major
>             Fix For: 6.5.0
>
>
> commons-io 2.16.0 has broken the implementation of 
> DeferredFileOutputStream changing the behavior of its superclass 
> ThresholdingOutputStream: https://issues.apache.org/jira/browse/IO-854
>  
> The class is used by commons-fileupload DiskFileItem, that is used by Struts 
> to handle multipart uploads. The issue causes each multipart part to be read 
> as empty.
>  
> A fix has been implemented in 2.16.1. However, the fix exposes an issue in 
> how the getFile of JakartaMultiPartRequest uses DiskFileItem, that causes it 
> to mishandle zero length inputs.
>  
> The issue is related to
> https://issues.apache.org/jira/browse/WW-5088
> https://issues.apache.org/jira/browse/WW-5146
>  
> Moreover, the fix implemented for this issues seems to be dubious and affects 
> not only file uploads but every field encoded as multipart/form-data: by 
> forcing the diskfileitem threshold to be -1, each and every field was written 
> to the filesystem.
>  
> The behavior of threadshold -1 was underspecified and inconsistent with the 
> commons-io implementation, and has been specified in 2.16.1.
>  
> To really fix the issue, I propose to avoid specifying -1 on the 
> DiskFileItemFactory and to properly handle the case when the 
> DiskFileItem.isInMemory() returns true in the JakartaMultiPartRequest.getFile 
> method: in this case getStoreLocation() is defined to return null and the 
> bytes should be read from memory instead.
>  
> Avoiding always spilling to disk each and every multipart part should also be 
> a performance win, considering that multipart can also be used to transfer 
> normal form inputs and not only files.
>  
> What do you think?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to