Looking at the code further, there is some code to support "multipart/related", but for some reason it doesn't seem to be being used in my use case. I will dig into it further and try to figure out what that's not being used in this case.
On Fri, May 2, 2025 at 1:21 PM Robert Turner <[email protected]> wrote: > Will do... I'll try to get a PR posted over the next couple of days. > > On Fri, May 2, 2025 at 1:20 PM Gary Gregory <[email protected]> > wrote: > >> Please add tests and create a PR. The tests are the best way to see the >> intent of the changes. >> >> Gary >> >> On Fri, May 2, 2025, 12:52 Robert Turner <[email protected]> >> wrote: >> >> > Thanks -- I have a local patch [1] on my machine (that I am just testing >> > now) if that is of interest to you (no tests added for it yet) >> > >> > [1] >> > diff --git >> > >> > >> a/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/AbstractFileUpload.java >> > >> > >> b/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/AbstractFileUpload.java >> > index 29876e9a..952b7920 100644 >> > --- >> > >> > >> a/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/AbstractFileUpload.java >> > +++ >> > >> > >> b/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/AbstractFileUpload.java >> > @@ -149,6 +149,11 @@ public abstract class AbstractFileUpload<R, I >> extends >> > FileItem<I>, F extends Fil >> > */ >> > private F fileItemFactory; >> > >> > + /** >> > + * Controls part detection and skipping. >> > + */ >> > + private boolean skipPartsWithoutNames = true; >> > + >> > /** >> > * Gets the boundary from the {@code Content-type} header. >> > * >> > @@ -558,4 +563,27 @@ public abstract class AbstractFileUpload<R, I >> extends >> > FileItem<I>, F extends Fil >> > this.sizeMax = sizeMax; >> > } >> > >> > + /** >> > + * Returns the current setting for skipping parts without names. >> The >> > default value is true. >> > + * >> > + * @return true if parts without form field names or file names >> will >> > be skipped, >> > + * false to include all parts. >> > + * @see #setSkipPartsWithoutNames(boolean) >> > + */ >> > + public boolean getSkipPartsWithoutNames() { >> > + return skipPartsWithoutNames; >> > + } >> > + >> > + /** >> > + * Enables or disables the skipping of parts with form field names >> or >> > file names. This >> > + * can be used by calling code to consume multipart payloads that >> are >> > not fully supported >> > + * by this library. >> > + * >> > + * @param skipPartsWithoutNames Indicates that parts without names >> > should be skipped. >> > + * The default value is true. >> > + * @see #getSkipPartsWithoutNames() >> > + */ >> > + public void setSkipPartsWithoutNames(final boolean >> > skipPartsWithoutNames) { >> > + this.skipPartsWithoutNames = skipPartsWithoutNames; >> > + } >> > } >> > diff --git >> > >> > >> a/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/FileItemInputIteratorImpl.java >> > >> > >> b/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/FileItemInputIteratorImpl.java >> > index 83fdfaaa..b40e927d 100644 >> > --- >> > >> > >> a/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/FileItemInputIteratorImpl.java >> > +++ >> > >> > >> b/commons-fileupload2-core/src/main/java/org/apache/commons/fileupload2/core/FileItemInputIteratorImpl.java >> > @@ -184,7 +184,7 @@ class FileItemInputIteratorImpl implements >> > FileItemInputIterator { >> > } >> > } else { >> > final var fileName = fileUpload.getFileName(headers); >> > - if (fileName != null) { >> > + if (!fileUpload.getSkipPartsWithoutNames() || fileName >> != >> > null) { >> > currentItem = new FileItemInputImpl(this, fileName, >> > currentFieldName, headers.getHeader(AbstractFileUpload.CONTENT_TYPE), >> > false, >> > getContentLength(headers)); >> > currentItem.setHeaders(headers); >> > >> > On Fri, May 2, 2025 at 12:45 PM Gary Gregory <[email protected]> >> > wrote: >> > >> > > I'll take a look at this and see if we can make it play nice with >> SOAP... >> > > >> > > Gary >> > > >> > > On Fri, May 2, 2025, 12:04 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 >> > > > >> > > >> > >> >
