Mateusz Poncyliusz created CAMEL-21403:
------------------------------------------
Summary: AS2 Component - Incorrect message length calculation
when generating MIC for EDI messages with multi-byte characters
Key: CAMEL-21403
URL: https://issues.apache.org/jira/browse/CAMEL-21403
Project: Camel
Issue Type: Bug
Affects Versions: 4.8.1
Reporter: Mateusz Poncyliusz
When I receive an EDI message Camel tries to generate MIC (Message Integrity
Code) and calls *public static byte[] getContent(HttpEntity entity)* in
{*}EntityUtils{*}, which then executes *entity.writeTo(os)* in
*ApplicationEntity.*
In line 67 [see
code|[https://github.com/apache/camel/blob/camel-4.8.x/components/camel-as2/camel-as2-api/src/main/java/org/apache/camel/component/as2/api/entity/ApplicationEntity.java]]
, the library incorrectly calculates the message length, which causes it to
truncate the content. Here is the relevant line:
{code:java}
transferEncodedStream.write(this.ediMessage.getBytes(this.getCharset()), 0,
this.ediMessage.length()); {code}
In this line, *this.ediMessage.getBytes(this.getCharset())*
retrieves the message content as a byte array, but *this.ediMessage.length()*
returns the length of the *String* in characters rather than in bytes. If the
*ediMessage* contains any multi-byte characters (e.g., "ó"), the *length*
method returns the count in characters, not in bytes, which leads to truncation.
For instance, in UTF-8, a character like "ó" uses two bytes, but
*ediMessage.length()* will return 1, not 2. This discrepancy causes *write()*
to only transfer part of the byte array, leading to an incorrect MIC
calculation and potential verification issues on the receiving end.
A potential fix is to use"{{{}{}}}
{code:java}
{code}
{{transferEncodedStream.write(this.ediMessage.getBytes(this.getCharset()));}}
instead of
{code:java}
transferEncodedStream.write(this.ediMessage.getBytes(this.getCharset()), 0,
this.ediMessage.length()); {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
