In the meantime, would you please confirm that a snapshot build for 2.0.0-SNAPSHOT works for you from https://repository.apache.org/content/repositories/snapshots/ ?
TY, Gary On Fri, May 2, 2025 at 2:34 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > I'll see about creating a release candidate over the next few days. > > Gary > > On Fri, May 2, 2025, 14:22 Robert Turner <rtur...@e-djuster.ca.invalid> wrote: >> >> Okay, so it seems the functionality I need has already been added in >> `master` [1] around 1 year ago, but hasn't been released yet. >> >> Is there a timeline for the next release? >> >> [1] https://github.com/apache/commons-fileupload/pull/315 >> >> >> On Fri, May 2, 2025 at 1:35 PM Robert Turner <rtur...@e-djuster.ca> wrote: >> >> > 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 <rtur...@e-djuster.ca> 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 <garydgreg...@gmail.com> >> >> 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 <rtur...@e-djuster.ca.invalid> >> >>> 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 <garydgreg...@gmail.com> >> >>> > 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 >> >>> <rtur...@e-djuster.ca.invalid> >> >>> > > 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 >> >>> > > > >> >>> > > >> >>> > >> >>> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
