[jira] [Resolved] (CAMEL-25217) camel-platform-http-vertx - a String response body is always written as UTF-8, even when the response Content-Type declares another charset (for example charset=ISO-8859-1), so the client decodes it wrongly

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-25217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-25217.
---------------------------------
    Fix Version/s: 4.23.0
       Resolution: Fixed

The fix is merged on main, so it is in Camel 4.23.0:
* 8b451798f592 CAMEL-25217: camel-platform-http-vertx - write a String response in the charset of the Content-Type
* bc4afdf796b1 CAMEL-25217: fix the Javadoc of responseCharset

Resolving, as the ticket was not updated when the PR was merged.

_Claude Code on behalf of Claus Ibsen_

> camel-platform-http-vertx - a String response body is always written as UTF-8, even when the response Content-Type declares another charset (for example charset=ISO-8859-1), so the client decodes it wrongly
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25217
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25217
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-platform-http-vertx
>            Reporter: shashank
>            Priority: Minor
>             Fix For: 4.23.0
>
>
> {{VertxPlatformHttpSupport.toHttpResponse}} copies the {{Content-Type}} of the message, with its {{charset}} parameter, to the response. {{writeResponse}} then writes a {{String}} body with
> {code:java}
> } else if (body instanceof String string) {
>     ctx.end(string);
> {code}
> and Vert.x encodes a {{String}} as UTF-8, whatever the declared charset. A client that decodes the response with the charset of the {{Content-Type}} (as it should, RFC 9110 8.3.1) gets mojibake for every non-ASCII character. Two common cases:
> * a route that sets {{Content-Type: text/plain; charset=ISO-8859-1}} and a {{String}} body ({{setBody(constant(...))}}, {{simple}}, {{transform}}): {{Grüße aus Köln}} (14 characters) is sent as 17 bytes of UTF-8 labelled ISO-8859-1, and read as {{Grü...}} (every non-ASCII character becomes two);
> * an echo, or any route that keeps the request {{Content-Type}}: a request with {{charset=ISO-8859-1}} is read correctly (the consumer sets {{CamelCharsetName}} from it), but the reply, labelled with the same {{Content-Type}}, is UTF-8.
> {{byte[]}}, {{InputStream}} and {{Buffer}} bodies are not affected, and neither is ASCII text, which is why the existing tests pass. The type converter {{VertxBufferConverter.toBuffer(String, Exchange)}} already uses the charset of the message {{Content-Type}} first, then {{CamelCharsetName}} (CAMEL-16282); the {{String}} branch of {{writeResponse}} bypasses it. (camel-servlet encodes a {{String}} in the exchange charset, {{CamelCharsetName}} or UTF-8, and only in non-chunked mode also sets the response character encoding to match; so it gets the echo case right but not a route that only sets the {{Content-Type}}.)
> h3. Reproduction
> {code:java}
> from("platform-http:/latin1")
>     .setHeader(Exchange.CONTENT_TYPE, constant("text/plain; charset=ISO-8859-1"))
>     .setBody(constant("Grüße aus Köln"));
> from("platform-http:/echo")
>     .convertBodyTo(String.class);
> {code}
> {{GET /latin1}} returns {{Content-Type: text/plain; charset=ISO-8859-1}} with the UTF-8 bytes of the text (17 bytes instead of 14). {{POST /echo}} with {{Content-Type: text/plain; charset=ISO-8859-1}} and the 14 ISO-8859-1 bytes returns 17 bytes. A unit test with both routes fails on main; the control with {{Content-Type: text/plain}} (no charset, UTF-8 expected) passes. A small formal model (Lean 4) shows that for every text with a character outside ASCII what a client reads with the declared ISO-8859-1 charset is longer than the text, and that writing in the declared charset returns every text the charset can represent.
> h3. Proposed fix
> Write the {{String}} in the charset of the response {{Content-Type}} when it declares one (and the JVM supports it), otherwise keep UTF-8 as today:
> {code:java}
> } else if (body instanceof String string) {
>     // write the text in the charset declared by the response Content-Type (vert.x writes a String as UTF-8)
>     String charset = responseCharset(ctx);
>     if (charset != null) {
>         ctx.end(Buffer.buffer(string, charset));
>     } else {
>         ctx.end(string);
>     }
>     promise.complete();
> private static String responseCharset(RoutingContext ctx) {
>     String contentType = ctx.response().headers().get("Content-Type");
>     if (contentType == null) {
>         return null;
>     }
>     String charset = IOHelper.getCharsetNameFromContentType(contentType);
>     if (charset == null || charset.isEmpty()) {
>         return null;
>     }
>     try {
>         return Charset.isSupported(charset) ? charset : null;
>     } catch (IllegalCharsetNameException e) {
>         return null;
>     }
> }
> {code}
> Only responses that declare a charset other than UTF-8 change, and for them the bytes now match the header. A response without a charset parameter stays UTF-8 (using {{CamelCharsetName}} there as well, like camel-servlet, would change the bytes of responses whose header does not say so, so it is left out). With the fix the new test and the whole camel-platform-http-vertx suite pass (150 tests, 1 skipped, camel-core built from the same commit). Because the bytes of these responses change, the change gets an upgrade guide note (a client that ignored the declared charset and read UTF-8 must now use the declared one; characters the declared charset cannot represent are written as {{?}}).
> Duplicate check (2026-09-30): JIRA "platform-http" with "charset", "encoding" or "UTF-8", and "VertxPlatformHttpSupport": CAMEL-16282, CAMEL-16756, CAMEL-22125, CAMEL-23320 (Spring Boot starter, binary data), none about a String body. No pull request about it.
> _Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v8.20.10#820010)