allthingssecurity opened a new pull request, #27852: URL: https://github.com/apache/camel/pull/27852
# Description [CAMEL-25634](https://issues.apache.org/jira/browse/CAMEL-25634) With a multipart request, `AttachmentHttpBinding.populateAttachments` adds every part, text fields included, as an attachment keyed by the field name. `populateRequestParameters` then mapped a parameter that has a `text/plain` (or untyped) attachment with `request.getParameter(name)`, which returns the first value only. A multipart form with `tag=integration`, `project=Camel`, `tag=routing` gave the header `tag` = `integration`; `routing` was lost. Checkbox groups and multi-selects send exactly this. Each value of `request.getParameterValues(name)` is now mapped (sanitized as before), so the header is a list of all values, as it already is for a repeated query or form-urlencoded parameter (the branch a few lines below). A file part is mapped as before (its `DataHandler`). Siblings (same request sent to each consumer in a differential test): camel-platform-http-vertx and camel-undertow map the repeated multipart field to a list of both values. What changes for users (4.24 upgrade guide entry): the header of a repeated multipart text field is a list instead of its first value. Side effect: Jetty's `getParameterValues` also returns the values of the query string. When a name appears both in the query and as a multipart text field, the header is now a list of both values instead of the first one. This is what the form-urlencoded branch of the same method already does for a name in the query and the form body. Not changed: several file parts with the same field name still keep one attachment (attachments are keyed by name), as in the other consumers. Tests: - New `MultiPartFormRepeatedFieldTest`. On main it fails: `expected: <[integration, routing]> but was: <integration>`. - camel-jetty with the change (built with `-am`, all 404 tests): 0 failures, 23 skipped, 1 error in `JettyXsltHttpTemplateTest`. That error is environmental: the test fetches the stylesheet from `0.0.0.0` and gets `Unexpected end of file from server` on my machine, and it fails the same way on main without this change. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [ ] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). (The ticket is drafted and not filed yet; CAMEL-25634 is a placeholder until it is.) # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-jetty, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
