allthingssecurity opened a new pull request, #27689: URL: https://github.com/apache/camel/pull/27689
# Description [CAMEL-25526](https://issues.apache.org/jira/browse/CAMEL-25526) `DefaultVertxHttpBinding.populateRequestHeaders` copied each message header to the request as `tc.convertTo(String.class, headerValue)`. For a collection that is its `toString()`, so a header holding `List.of("a", "b")` was sent as the single line `X-Test: [a, b]`, and a `String[]` as `[Ljava.lang.String;@...`. The HTTP consumers map a request header that occurs more than once to a List, so a route forwarding such a request with vertx-http (a proxy, or HTTP/2 clients that send each cookie in its own `cookie` header) sent corrupted values without an error. Now the binding iterates a value that is an `Iterable` or an `Object[]` as camel-http does (`ObjectHelper.createIterator(headerValue, null, true)` and `HttpUtil.applyHeader`, which applies the header filter per value and skips null values) and sets all the values of the header, as camel-netty-http and camel-undertow also do. Every other value takes the same code as before (header filter, then one `tc.convertTo(String.class, headerValue)`): a String (also one with commas), a number, and a `byte[]` or another primitive array, which are deliberately not iterated, so a `byte[]` header (a Kafka record header, for example) is still sent as one String and not as one header per byte. A 4.23 upgrade guide note describes the change. Tests: - New `VertxHttpMultiValueHeaderTest` (undertow test server that echoes the values of `X-Test` it receives): a List header, an array header, a String with a comma, and a `byte[]`. - On main the List and the array test fail: `expected: <a|b> but was: <[a, b]>` and `expected: <a|b> but was: <[Ljava.lang.String;@...>`. The String and the `byte[]` test pass on main too; they are kept because they pin the two values an iterating fix can break: iterating with a delimiter splits `"a, b"`, and iterating every array gave `expected: <abc> but was: <97|98|99>` for the `byte[]` in an earlier version of this change. - With the change: camel-vertx-http 101 tests, 0 failures (1 skipped, as on main). Not changed here: camel-knative-http has the same problem (`KnativeHttpProducer` copies the request headers with `toString()`, and the reply of `KnativeHttpConsumer` keeps only the last value of a header). It is a separate component and is handled in a separate ticket. Found with a Lean 4 model of the header copy: "a header is sent as one line per value" (what camel-http does) fails for `["a", "b"]` and is proved to fail for every list value, and the fix is proved to equal camel-http's behaviour for every value of the model (a String or a list of Strings) and to send the same line as before for every String. I then reproduced it with the producer. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] 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). # 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-vertx-http, 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]
