The snapshot repository and git master are the same ATM. Thank you for
testing.

Gary


On Fri, May 2, 2025, 15:25 Robert Turner <[email protected]>
wrote:

> The current HEAD of the master branch does work for me (I built and tested
> it locally with our application). I can pull the specific snapshot if you
> would prefer, but I'm pretty confident the "current code" is doing what I
> expect.
>
> On Fri, May 2, 2025 at 2:39 PM Gary Gregory <[email protected]>
> wrote:
>
> > 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 <[email protected]>
> > wrote:
> > >
> > > I'll see about creating a release candidate over the next few days.
> > >
> > > Gary
> > >
> > > On Fri, May 2, 2025, 14:22 Robert Turner <[email protected]
> >
> > 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 <[email protected]>
> > 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 <[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
> > >> >>> > > >
> > >> >>> > >
> > >> >>> >
> > >> >>>
> > >> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>

Reply via email to