[jira] [Updated] (CAMEL-25034) convertBodyTo(type, charset) ignores the charset when the message has a CamelCharsetName header, and leaves it on the exchange when the conversion fails

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

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

Claus Ibsen updated CAMEL-25034:
--------------------------------
    Fix Version/s: 4.23.0

> convertBodyTo(type, charset) ignores the charset when the message has a CamelCharsetName header, and leaves it on the exchange when the conversion fails
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25034
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25034
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>            Reporter: shashank
>            Priority: Minor
>             Fix For: 4.23.0
>
>
> {{convertBodyTo(String.class, "UTF-8")}} (and {{convertHeaderTo}} / {{convertVariableTo}} with a charset) is the documented way to convert with a given charset. {{ConvertBodyProcessor.process}} ({{ConvertBodyProcessor.java:119-173}}) passes the charset to the type converters by setting the exchange *property* {{CamelCharsetName}}, converts, and then restores the old property:
> {code:java}
> originalCharsetName = exchange.getProperty(ExchangePropertyKey.CHARSET_NAME, String.class);
> // override existing charset with configured charset as that is what the user
> // have explicit configured and expects to be used
> exchange.setProperty(ExchangePropertyKey.CHARSET_NAME, charset);
> value = old.getMandatoryBody(type);                 // :143
> ...
> // remove or restore charset when we are done as we should not propagate that   (:163-171, not in a finally)
> {code}
> Two problems:
> # The converters read the charset with {{ExchangeHelper.getCharsetName/getCharset}} ({{ExchangeHelper.java:958-1001}}), where the {{CamelCharsetName}} *header* "takes precedence" over the property. When the message carries that header (the HL7 data format sets it, {{HL7DataFormat.java:153}}, and user routes set it), the configured charset is silently ignored and the body is decoded with the header's charset.
> # The restore is skipped when the conversion throws. The configured charset then stays on the exchange, and the error handler, {{onException}} and the dead letter channel convert the body with it.
> {{ConvertHeaderProcessor.java:132-160}} and {{ConvertVariableProcessor.java:157-185}} have the same code.
> *Reproduction* (standalone program against main dbdd4b381):
> {noformat}
> from("direct:conv").convertBodyTo(String.class, "UTF-8")
>   body = "café" as UTF-8 bytes, no header                       -> café     (correct)
>   body = "café" as UTF-8 bytes, header CamelCharsetName=ISO-8859-1 -> café    expected café
> from("direct:fail").onException(Exception.class).handled(true).setBody(simple("${exchangeProperty.CamelCharsetName}")).end()
>                    .convertBodyTo(Integer.class, "UTF-16")
>   body "abc"                                                       -> UTF-16   expected (empty)
> {noformat}
> Property-based tests (jqwik): with the header, {{convertBodyTo(String.class, "UTF-8")}} of UTF-8 bytes fails for random Latin-1 text (shrunk sample {{à}}); without the header it passes 500 tries; after a failing conversion the property is left behind (shrunk sample {{a}}).
> A Lean model proves the following:
> * Whenever a header with a different charset is present, the configured charset is not used ({{header_always_wins}}), and every failing conversion leaves the configured charset in the property ({{failure_always_leaks}}).
> * Without the header, a successful conversion uses the configured charset and restores the property ({{no_header_ok}}), and without a configured charset nothing changes ({{unconfigured_ok}}), so the fix only changes the two cases above.
> The same property-based code is in camel-2.25.4 and camel-3.0.0 ({{ConvertBodyProcessor}}), camel-4.0.0 and camel-4.14.0, and the header precedence in {{ExchangeHelper.getCharsetName}} is the same since 3.0, so all maintained versions are affected. CAMEL-12279 (2.21) added the restore of the original property, but not in a {{finally}} block and not for the header.
> *Proposed fix:* in the three processors:
> * if the message has a {{CamelCharsetName}} header, remember it and remove it (or set it to the configured charset) for the duration of the conversion, the same way as the property;
> * restore the header and the property in a {{finally}} block.
> Alternatively, pass the charset to the conversion directly instead of through the exchange, but the type converters only read it from the exchange today.
> Tests: {{ConvertBodyTest}} with a {{CamelCharsetName=ISO-8859-1}} header and {{convertBodyTo(String.class, "UTF-8")}} of UTF-8 bytes with non-ASCII text; and a failing {{convertBodyTo(Integer.class, "UTF-16")}} followed by a check that the exchange property is unchanged.
> _Filed with Claude Code on behalf of allthingssecurity._



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