[
https://issues.apache.org/jira/browse/WW-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Riccardo Proserpio updated WW-5413:
-----------------------------------
Description:
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 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?
was:
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?
> 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 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)
