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
