allthingssecurity opened a new pull request, #27245: URL: https://github.com/apache/camel/pull/27245
# Description [CAMEL-25248](https://issues.apache.org/jira/browse/CAMEL-25248) The Undertow consumer converted a response body to a `ByteBuffer`, and the producer a request body, without passing the exchange to the type converter, so a `String` body was always encoded as UTF-8: - a route that sets `Content-Type: text/plain; charset=ISO-8859-1` and a `String` body sent `Grüße aus Köln` (14 characters) as 17 bytes of UTF-8 labelled ISO-8859-1; - an echo of an ISO-8859-1 request (read correctly: the consumer sets `CamelCharsetName` from the request charset) answered in UTF-8 under the same `Content-Type`; - the producer sent UTF-8 bytes under a `Content-Type` that declares ISO-8859-1. camel-servlet/camel-jetty, camel-http and camel-netty-http honour the exchange charset, and camel-platform-http-vertx the `Content-Type` charset (CAMEL-25217, the same defect). This change: a `String` body is encoded in the charset declared by the `Content-Type` of the request or response being sent (`UndertowHelper.toByteBuffer`), as CAMEL-25217 does for platform-http-vertx. Without a declared charset, and for other bodies, the conversion is unchanged (UTF-8). `CamelCharsetName` is not used as a fallback: Undertow does not declare it in the header (camel-servlet does, with `setCharacterEncoding`), so a response to an ISO-8859-1 request with `Content-Type: application/json` would otherwise be written in ISO-8859-1 while the client reads UTF-8. Messages without a charset, or with UTF-8, are sent with the same bytes as before; the others now match their header, so the upgrade guide for 4.23 gets a note. Tests: - `UndertowStringBodyCharsetTest` (new): a response that declares ISO-8859-1, an echo of an ISO-8859-1 request, the producer with an ISO-8859-1 `Content-Type`, and two controls that must stay UTF-8: a `text/plain` response, and a `text/plain` response to an ISO-8859-1 request. - Without the change the first three fail (`array lengths differ, expected: <14> but was: <17>`); the controls pass. - With the change all camel-undertow tests pass: 196 tests, 0 failures, 1 skipped. Backport note: the change does not read `CamelCharsetName`, so it does not depend on 892be63447 (on 4.14.x/4.18.x the consumer still sets it to ISO-8859-1 for a request without a charset). # 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 the affected module, 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]
