shashank created CAMEL-25355:
--------------------------------
Summary: camel-support - an empty charset parameter of the
Content-Type (charset=) sets an empty CamelCharsetName, and converting the body
then fails (servlet, Jetty and HTTP producer)
Key: CAMEL-25355
URL: https://issues.apache.org/jira/browse/CAMEL-25355
Project: Camel
Issue Type: Bug
Components: camel-support, camel-http-common, camel-servlet,
camel-http, camel-core, camel-jetty
Reporter: shashank
The shared helpers that read the charset parameter of a {{Content-Type}} return
an empty name for an empty value, such as {{text/plain; charset=}},
{{charset=""}} or {{charset=; format=flowed}}:
* {{IOHelper.getCharsetNameFromContentType}} (camel-util) returns {{""}}
instead of its default {{UTF-8}};
* {{HttpUtil.getCharsetFromContentType}} (camel-support, used by
{{HttpUtil.setCharsetFromContentType}} and
{{org.apache.camel.http.common.HttpHelper.setCharsetFromContentType}}) returns
{{""}} instead of {{null}}.
The callers store this as the {{CamelCharsetName}} exchange property:
{{CamelServlet}} (servlet consumer), {{CamelContinuationServlet}} (Jetty
consumer), {{HttpProducer}} (response headers and response body),
{{DefaultVertxHttpBinding}} (vertx-http producer).
{{DefaultHttpBinding.readHeaders}} does the same with
{{HttpServletRequest.getCharacterEncoding()}}, which is also {{""}} for these
values on Tomcat ({{charset=}}, {{charset=""}}) and Undertow ({{charset=""}},
{{charset=; ...}}). Every later conversion of the body that uses the exchange
charset then fails in {{Charset.forName("")}}:
{noformat}
org.apache.camel.TypeConversionException: Error during type conversion from
type: byte[] to the required type: java.lang.String due to
java.nio.charset.IllegalCharsetNameException:
at java.nio.charset.Charset.forName(Charset.java:539)
at
org.apache.camel.support.ExchangeHelper.getCharset(ExchangeHelper.java:1005)
{noformat}
So a servlet or Jetty route that reads the body as a String answers 500, and an
HTTP producer cannot read the response body as a String. The form parser of
{{DefaultHttpBinding}} ({{application/x-www-form-urlencoded; charset=""}}) also
fails ({{URLDecoder.decode(.., "")}}).
{{UndertowHelper.getCharsetFromContentType}} already treats an empty value as
no charset, and the same was done for {{NettyHttpHelper}} in CAMEL-25305
(raised by Claus Ibsen in the review).
h3. Reproduction
* camel-util {{IOHelperTest.testCharsetEmpty}}: {{expected: <UTF-8> but was:
<>}}; camel-support new {{HttpUtilTest}}: {{expected: <null> but was: <>}}.
* camel-servlet new {{ServletEmptyCharsetParameterTest}} (embedded Undertow): a
POST with {{text/plain; charset=; format=flowed}}, {{charset=""}} or {{charset=
;format=flowed}} to a route doing {{convertBodyTo(String.class)}}, and a form
POST with {{charset=""}}: all 4 answer 500 on main.
* camel-jetty new {{JettyEmptyCharsetParameterTest}}: a POST with {{text/plain;
charset=}}: 500 on main.
* camel-http new {{HttpProducerEmptyCharsetParameterTest}}: a response with any
of the three empty forms: {{TypeConversionException}} on main (3 of 3).
All fail in two runs on main.
h3. Proposed fix
Treat an empty (or blank) charset value as no charset, as {{UndertowHelper}}
and {{NettyHttpHelper}} do: {{IOHelper.getCharsetNameFromContentType}} returns
its default {{UTF-8}}, {{HttpUtil.getCharsetFromContentType}} returns {{null}}
(so no property is set), and {{DefaultHttpBinding}} ignores an empty
{{getCharacterEncoding()}} (and parses a form as UTF-8, as without a charset).
Content types with a charset, or without one, are handled as before. No upgrade
note: the only change is for requests and responses that failed before, apart
from the corner case below.
Other callers of {{IOHelper.getCharsetNameFromContentType}} see {{UTF-8}}
instead of {{""}} for an empty charset parameter: the vertx-http producer
({{DefaultVertxHttpBinding}}) stored {{""}} as {{CamelCharsetName}} and failed
in the same way, and now uses UTF-8; {{VertxPlatformHttpSupport}} (CAMEL-25217)
treated {{""}} as no charset and wrote a String response as UTF-8, which it
still does. {{VertxBufferConverter}} and
{{VertxHttpHelper.getCharsetFromExchange}} fell back to the
{{CamelCharsetName}} exchange property for {{""}}; they now use UTF-8, as they
already did for a Content-Type without a charset. So a {{Buffer}}/{{String}}
conversion for a message whose Content-Type has an empty charset parameter and
that also has a {{CamelCharsetName}} other than UTF-8 now uses UTF-8.
Not in Camel, so not changed: the embedded Undertow itself fails on a
{{charset=}} at the very end of the header ({{StringIndexOutOfBoundsException}}
in {{Headers.extractQuotedValueFromHeader}}), and Jetty 12 itself rejects
{{charset=""}} and {{charset=; ...}} in {{getContentType()}}.
Together with the CAMEL-25316 and CAMEL-25133 changes to {{DefaultHttpBinding}}
(merged without conflict) the camel-util, camel-support, camel-http-base,
camel-http-common, camel-servlet, camel-jetty-common, camel-http, camel-jetty
(except the environment-dependent {{JettyXsltHttpTemplateTest}}),
camel-vertx-http and camel-platform-http-vertx tests pass.
Affected: 4.14.x, 4.18.x and main (same code).
Priority Minor: only requests or responses with a malformed (empty) charset
parameter are affected, but they fail instead of being read as UTF-8.
Duplicate check (2026-10-05): JIRA "IllegalCharsetNameException" (3 issues,
none on this), "getCharsetNameFromContentType" (4: CAMEL-25295, CAMEL-12395,
CAMEL-25084, CAMEL-25217), "normalizeCharset" (CAMEL-12424, a charset that is
not the last parameter), "HttpUtil" with charset (CAMEL-25305, CAMEL-24594),
summary "empty charset" (none). GitHub pull requests "empty charset",
"getCharsetNameFromContentType", "IllegalCharsetNameException": only the merged
CAMEL-25305, CAMEL-25295, CAMEL-25084 and CAMEL-25217.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
