[
https://issues.apache.org/jira/browse/WW-5413?focusedWorklogId=1031665&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1031665
]
ASF GitHub Bot logged work on WW-5413:
--------------------------------------
Author: ASF GitHub Bot
Created on: 22/Jul/26 13:09
Start Date: 22/Jul/26 13:09
Worklog Time Spent: 10m
Work Description: sonarqubecloud[bot] commented on PR #1805:
URL: https://github.com/apache/struts/pull/1805#issuecomment-5046147738
## [](https://sonarcloud.io/dashboard?id=apache_struts&pullRequest=1805)
**Quality Gate passed**
Issues
 [7 New
issues](https://sonarcloud.io/project/issues?id=apache_struts&pullRequest=1805&issueStatuses=OPEN,CONFIRMED&sinceLeakPeriod=true)
 [0 Accepted
issues](https://sonarcloud.io/project/issues?id=apache_struts&pullRequest=1805&issueStatuses=ACCEPTED)
Measures
 [0 Security
Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_struts&pullRequest=1805&issueStatuses=OPEN,CONFIRMED&sinceLeakPeriod=true)
 [84.8% Coverage on New
Code](https://sonarcloud.io/component_measures?id=apache_struts&pullRequest=1805&metric=new_coverage&view=list)
 [2.5% Duplication on New
Code](https://sonarcloud.io/component_measures?id=apache_struts&pullRequest=1805&metric=new_duplicated_lines_density&view=list)
<!
Issue Time Tracking
-------------------
Worklog Id: (was: 1031665)
Time Spent: 40m (was: 0.5h)
> 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: 40m
> 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)
