Riccardo Proserpio created WW-5413:
--------------------------------------
Summary: 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
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)
