Major Description
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?