[jira] [Updated] (WW-5413) Multipart misbehavior with commons-io 2.16.0 and 2.16.1
[ https://issues.apache.org/jira/browse/WW-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart updated WW-5413: -- Fix Version/s: 7.0.0 (was: 6.5.0) > 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: 7.0.0 > > > 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)
[jira] [Updated] (WW-5413) Multipart misbehavior with commons-io 2.16.0 and 2.16.1
[ https://issues.apache.org/jira/browse/WW-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart updated WW-5413: -- 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? 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 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? > 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: 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 defi
[jira] [Updated] (WW-5413) Multipart misbehavior with commons-io 2.16.0 and 2.16.1
[ 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
[jira] [Updated] (WW-5413) Multipart misbehavior with commons-io 2.16.0 and 2.16.1
[ https://issues.apache.org/jira/browse/WW-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart updated WW-5413: -- Fix Version/s: 6.5.0 > 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 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)