allthingssecurity opened a new pull request, #27594: URL: https://github.com/apache/camel/pull/27594
# Description [CAMEL-25457](https://issues.apache.org/jira/browse/CAMEL-25457) Follow-up to a point @davsclaus raised in the review of #27392 (CAMEL-25316): `DefaultHttpBinding.doWriteDirectResponse` writes a `String` response that is not chunked (`chunked=false` or the `CamelHttpChunked` header) and has a text `Content-Type` (`isText`: it contains `text` or `html`) through its last fallback, which calls `response.setCharacterEncoding(exchange charset)`. That replaces the charset of the `Content-Type` the route set, so `text/plain; charset=ISO-8859-1` is sent as `text/plain;charset=UTF-8` (the request charset, else UTF-8). Body, header and Content-Length agree (CAMEL-5265), so the client decodes the text, but the declared charset is ignored. After CAMEL-25316 the chunked and non-text paths honour it, so this was the last path of camel-servlet and camel-jetty that did not. This change uses the charset that the `Content-Type` declares in that fallback, for the Content-Length and `setCharacterEncoding`, when the body is a `String` and the charset is supported. The parsing from CAMEL-25316 is moved into a small `getContentTypeCharset` helper used by both places (no change for the other paths). Responses without a declared charset, with an unsupported one, and bodies that are not a `String` are written in the exchange charset as before; a non-`String` body (for example `byte[]`) is converted to a `String` with the exchange charset, so re-encoding it in another charset would change its bytes (the undertow, netty-http and platform-http-vertx fixes also only change `String` bodies). Characters that the declared charset cannot represent are written as `?`. Upgrade guide entry added under the CAMEL-25316 heading. Cost: one parse of the `Content-Type` per such response, only for a `String` body. Tests: `ServletStringResponseCharsetTest` (camel-servlet). The non-chunked text case now checks the charset of the response `Content-Type`, the Content-Length and the bytes: it fails without the change (`expected: <ISO-8859-1> but was: <UTF-8>`, header `text/plain;charset=UTF-8`) and passes with it. New `notChunkedTextResponseWithoutDeclaredCharset` checks that a `Content-Type` without a charset still uses the exchange charset (passes with and without the change). camel-http-common (39 tests), camel-servlet (106, 2 skipped) and camel-jetty (398, 23 skipped) pass, except `JettyXsltHttpTemplateTest`, which fails on my machine with and without the change (`0.0.0.0` binding). This touches `DefaultHttpBinding` like #27530 (CAMEL-25355, request side); the two merge without conflict. # 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 modules, 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]
