[
https://issues.apache.org/jira/browse/CAMEL-25295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-25295:
--------------------------------
Fix Version/s: 4.23.0
> camel-undertow - the charset parameter of the Content-Type is only recognized
> in lower case (Charset=ISO-8859-1 is read and written as UTF-8)
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25295
> URL: https://issues.apache.org/jira/browse/CAMEL-25295
> Project: Camel
> Issue Type: Bug
> Components: camel-undertow
> Reporter: shashank
> Priority: Minor
> Fix For: 4.23.0
>
>
> camel-undertow finds the charset of a {{Content-Type}} with Undertow's
> {{Headers.extractQuotedValueFromHeader(contentType, "charset")}}, which
> matches the parameter name case-sensitively. Parameter names are
> case-insensitive (RFC 9110, section 5.6.6), so {{text/plain;
> Charset=ISO-8859-1}} declares ISO-8859-1 too. On main:
> * *Consumer, request:* {{CamelCharsetName}} (and
> {{CamelHttpCharacterEncoding}}) is not set, so the request body is converted
> to a {{String}} as UTF-8: ISO-8859-1 text becomes mojibake.
> * *Consumer, response, and producer, request:* since CAMEL-25248 a {{String}}
> body is written in the charset that the {{Content-Type}} declares; with
> {{Charset=}} it is still written as UTF-8 while the header says ISO-8859-1.
> The other HTTP components match the name case-insensitively with
> {{IOHelper.getCharsetNameFromContentType}}: camel-http-base {{HttpHelper}}
> (servlet, http-common), the camel-http producer, camel-jetty,
> camel-vertx-http and the Vert.x buffer converter.
> h3. Reproduction
> Three new tests in {{UndertowStringBodyCharsetTest}}, all with {{text/plain;
> Charset=ISO-8859-1}} and the text {{Grüße aus Köln}}; on main all three fail:
> * response of a route that sets that {{Content-Type}}: 17 bytes (UTF-8)
> instead of 14;
> * request in ISO-8859-1 to a route that converts the body to a {{String}} and
> answers in UTF-8: 20 bytes instead of 17 (the request was decoded as UTF-8);
> * producer request: the server receives 17 bytes instead of 14.
> h3. Proposed fix
> A new {{UndertowHelper.getCharsetFromContentType}} finds the {{charset}}
> parameter case-insensitively (as {{IOHelper.getCharsetNameFromContentType}}
> does), and both the consumer (request charset) and
> {{UndertowHelper.toByteBuffer}} (String bodies of the consumer response and
> the producer request) use it. Unlike
> {{IOHelper.getCharsetNameFromContentType}} it has no UTF-8 default: a
> {{Content-Type}} without a charset still sets no {{CamelCharsetName}} /
> {{CamelHttpCharacterEncoding}} (the deliberate behaviour of 892be63447, as in
> the camel-platform-http-vertx consumer), and a String body without a charset
> is converted as before. The declared value is kept as written (quotes
> removed). A fourth test guards the no-charset case. With the fix the four
> tests and the camel-undertow suite (200 tests, 1 skipped) pass. The upgrade
> guide gets a subsection under the camel-undertow entry of CAMEL-25248.
> Affected: main for both sides (the String body side is new in 4.23,
> CAMEL-25248). The request side also on 4.14.x and 4.18.x: there the consumer
> sets {{CamelCharsetName}} from Undertow's {{getRequestCharset()}}, which uses
> the same case-sensitive match and falls back to ISO-8859-1, so a request with
> {{Charset=UTF-8}} is read as ISO-8859-1 (main reads the charset itself since
> the chore commit 892be63447, #22471).
> Duplicate check (2026-10-02, again 2026-10-03): JIRA component camel-undertow
> with text "charset" / "Content-Type": only CAMEL-25248. GitHub: the nit by
> the reviewer on #27245 (davsclaus, "a follow-up is fine"); no open PR on
> these files (#22358 changes other undertow files).
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
