OK great, I'll create a release candidate this week. Gary
On Mon, May 5, 2025, 09:55 Robert Turner <rtur...@e-djuster.ca.invalid> wrote: > @Gary I've just pulled all your changes from yesterday into a local > (unmodified) snapshot build (master branch), and run through our automated > product tests and all looks good for our usage. > > Robert > > On Fri, May 2, 2025 at 4:58 PM Gary Gregory <garydgreg...@gmail.com> > wrote: > > > The snapshot repository and git master are the same ATM. Thank you for > > testing. > > > > Gary > > > > > > On Fri, May 2, 2025, 15:25 Robert Turner <rtur...@e-djuster.ca.invalid> > > 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 <garydgreg...@gmail.com> > > > 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 <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 > > > > > > > > > > > > > >
