On Fri, May 2, 2025 at 12:37 PM <[email protected]> wrote: > So I'm more of a lurker on this mail group, but your request is intriguing. > > Why can't you just set the filename to something other than null? It > seems to me that a simple "X-SOAP-Attachment" would suffice without making > library changes or needing to write a patch? >
I don't control the code sending the payloads.... > > Sent with Spark > On May 2, 2025, 9:04 AM -0700, Robert Turner <[email protected]>, > wrote: > > I've been trying to find a solution to easily allow receiving attachments > > in a multipart payload (such as "multipart/related") [1]. The FileUpload > > library comes very close to allowing us to at least receive such parts. > > > > However, with the current implementation (2.0.0-M2) > > of FileItemInputIteratorImpl [3], any parts without a form field name > > ("name" value in the Content-Disposition header) or a file name > ("filename" > > value in the Content-Disposition header) are discarded. A related, but > not > > identical, work item is in the project jira, as FILEUPLOAD-281 [2], but > > this is quite an old item (from 2017) and the proposed patch is likely no > > longer suitable. > > > > I have been looking at the code, and I'm wondering if there is an easy > way > > that at least partial support for these "unsupported" multipart payloads > > could be added without much effort. At a fairly quick glance, it looks > like > > one could eliminate or bypass the `if (fileName == null)` check in > > FileItemInputIteratorImpl::findNextItem [3], and it "would work" -- > > however, any code that relied on having a file name might fail -- but I > > don't see anything in the library that would fail, it would be client > code > > most likely that would fail (a breaking change). > > > > As such, a change like that would likely want to be controlled by some > > "flag" or similar when constructing the "FileUpload" object (derived from > > AbstractFileUpload [4]), or by adding a method to control that flag to > > AbstractFileUpload [4]. > > > > I am happy to implement a solution / patch and post a PR / change, but > > given that I am not intimately familiar with the project, the proposals / > > suggestions above may not be in line with how the project wants to > evolve, > > etc. If adding such functionality (or similar) is not desirable, I will > > likely resort to patching it in some way to at least bypass this > > limitation, or trying to find another solution / library. > > > > As such, feedback on this would be greatly appreciated before I invest > > additional effort going in the "wrong direction". > > > > Thanks for any feedback anyone can provide, > > > > Robert > > > > > > [1] Motivation for this comes from trying to support a "SOAP with > > attachments" style interface (not popular, but unfortunately used by a > > product we need to integrate with, and is unchangeable by us). The > > related W3 document for this is "SOAP-attachments" ( > > https://www.w3.org/TR/SOAP-attachments), which uses the Content-ID part > > header to identify parts instead of form fields or filenames. > > > > [2] https://issues.apache.org/jira/browse/FILEUPLOAD-281 > > > > [3] > > > https://github.com/apache/commons-fileupload/blob/master/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/FileItemInputIteratorImpl.java#L127 > > > > [4] > > > https://github.com/apache/commons-fileupload/blob/master/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/AbstractFileUpload.java >
