[
https://issues.apache.org/jira/browse/CAMEL-25305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-25305.
---------------------------------
Fix Version/s: 4.23.0
Resolution: Fixed
The fix is merged on main, so it is in Camel 4.23.0:
* 6d66f0852a08 CAMEL-25305: camel-netty-http - write a String body in the
charset that the Content-Type declares
* f89928713ba7 CAMEL-25305: camel-netty-http - an empty charset parameter is no
charset
Resolving, as the ticket was not updated when the PR was merged.
_Claude Code on behalf of Claus Ibsen_
> camel-netty-http - a String body is sent in the exchange charset, not in the
> charset the Content-Type declares, and the request charset parameter is only
> recognized in lower case
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25305
> URL: https://issues.apache.org/jira/browse/CAMEL-25305
> Project: Camel
> Issue Type: Bug
> Components: camel-netty-http
> Reporter: shashank
> Priority: Minor
> Fix For: 4.23.0
>
>
> h3. 1. String body
> {{DefaultNettyHttpBinding}} converts a body that is not a {{ByteBuf}} with
> {{message.getBody(ByteBuf.class)}}, which for a {{String}} uses the exchange
> charset ({{CamelCharsetName}}, UTF-8 when not set), and copies the
> {{Content-Type}} header unchanged. So a route that answers with {{text/plain;
> charset=ISO-8859-1}} and the text {{Grüße aus Köln}} sends 17 UTF-8 bytes
> labelled ISO-8859-1, and a client that honours the header reads {{Grüße aus
> Köln}}. The producer does the same for the request body. Bytes, streams and
> {{ByteBuf}} bodies are not affected, and neither are messages whose declared
> charset is the exchange charset.
> camel-platform-http-vertx (CAMEL-25217) and camel-undertow (CAMEL-25248) were
> fixed for this in 4.23; camel-http uses the {{Content-Type}} charset for a
> String entity, and the servlet binding sets the response character encoding
> so the header matches the bytes.
> h3. 2. Charset parameter in upper case
> The consumer ({{HttpServerChannelHandler}}) and
> {{NettyHttpConverter.toString(FullHttpResponse)}} find the request charset
> with the deprecated {{HttpUtil.getCharsetFromContentType}}, i.e.
> {{contentType.indexOf("charset=")}}. Parameter names are case-insensitive
> (RFC 9110, section 5.6.6): with {{Content-Type: text/plain;
> Charset=ISO-8859-1}} no {{CamelCharsetName}} is set and the body is decoded
> as UTF-8 ({{Gr��e aus K�ln}}).
> h3. Reproduction
> New {{NettyHttpStringBodyCharsetTest}} (JDK HTTP client against a netty-http
> consumer): response of a route that sets {{text/plain; charset=ISO-8859-1}}:
> 17 bytes instead of 14; request with {{Charset=ISO-8859-1}}: the route reads
> mojibake; producer request with {{charset=ISO-8859-1}}: the server receives
> 17 bytes instead of 14. Control: a response without a charset is UTF-8
> (passes on main). A unit test of the new charset lookup pins that a
> {{Content-Type}} without a charset parameter gives no charset (not a UTF-8
> default).
> h3. Proposed fix
> * A String body is converted with the charset the {{Content-Type}} declares
> when there is one (and it is supported); otherwise as before.
> * A new {{NettyHttpHelper.getCharsetFromContentType}} finds the {{charset}}
> parameter case-insensitively (no UTF-8 default, so no {{CamelCharsetName}} is
> set when the header declares none, as today); used by the consumer and the
> converter instead of the deprecated helper.
> * Upgrade guide note for 4.23 (as for camel-undertow).
> With the fix the 5 new tests and the module pass (281 tests, 8 skipped). As
> in camel-undertow and camel-http ({{StringEntity}} with the Content-Type),
> the declared charset wins over {{CamelCharsetName}}; without a declared
> charset the exchange charset is used as today.
> Found with the Lean 4 model of the String body encoding written for
> CAMEL-25217, applied to camel-netty-http: the property "a peer that decodes
> with the declared charset reads the text that was sent" fails for every text
> with a character outside US-ASCII (theorem {{main_corrupts}}) and holds with
> the fix; the case-sensitive parameter lookup misses {{Charset=}}
> ({{cex_upper}}).
> Affected: 4.14.x, 4.18.x and main (same code).
> Duplicate check (2026-10-03): JIRA component camel-netty-http with text
> "charset" (only CAMEL-6872, an action parameter in the Content-Type, fixed in
> 2.x); GitHub pull requests "netty-http charset", "netty-http Content-Type
> charset": none.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
