shashank created CAMEL-25295:
--------------------------------
Summary: 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
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)
