[jira] [Work started] (WW-5413) Multipart misbehavior with commons-io 2.16.0 and 2.16.1

["Lukasz Lenart (Jira)" <ji...@apache.org>]

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

Work on WW-5413 started by Lukasz Lenart.
-----------------------------------------
> 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
>            Assignee: Lukasz Lenart
>            Priority: Major
>             Fix For: 7.3.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> commons-io 2.16.0 has broken the implementation of 
> DeferredFileOutputStream changing the behavior of its superclass ThresholdingOutputStream: 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 WW-5088 and 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 suggest 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)