[
https://issues.apache.org/jira/browse/CAMEL-21505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17912000#comment-17912000
]
Meinolf S-D edited comment on CAMEL-21505 at 1/10/25 3:49 PM:
--------------------------------------------------------------
Hi [~jono],
I would give some more information on how I have tested this when I found the
issue.
I have used Mendelson AS2 Server as Client to send the AS2 Message to Camel AS2.
In Mendelson I have configured 'Content Transfer Encoding:' 'base64' and
'Payload content type:' 'application/EDI-Consent'.
I sent a zip file containing some content items during my tests.
When receiving the file in the processor it was already corrupted and after
saving it to the filesystem the zip file can't be opened.
After debugging the the Camel AS2 module I saw it gets corrupt in
EntityUtil.decode method because the base64 encoded zip file is decoded to a
native zip byte[].
The decoded native zip byte[] then is given as a parameter to a String
Constructor which obviously lets a binary get corrupt.
Here is a screenshot of the Mendelson AS2 Partner Configuation
!image-2025-01-10-15-09-59-096.png|width=629,height=460!
In your provided Unit Tests you have choosen '7bit' content transfer encoding
instead of 'base64' content transfer encoding:
EDI_MESSAGE_CONTENT_TRANSFER_ENCODING = "7bit"
This is a different approach. If you are choosing 'base64' content transfer
encoding the decode method in EntityUtils will run into 'case "base64"' and do
a decode of the base64 encoded zip and give the decoded byte[] to the String
constructor.
{code:java}
switch (encoding.toLowerCase()) {
case "base64":
return Base64.decode(data);
case "quoted-printable":
return QuotedPrintableCodec.decodeQuotedPrintable(data);
case "binary":
case "7bit":
case "8bit":
// Identity encoding
return data;
default:
throw new CamelException("Unknown encoding: " + encoding);
} {code}
Possibly this helps for the reproduction.
was (Author: JIRAUSER307851):
Hi [~jono],
I would give some more information on how I have tested this when I found the
issue.
I have used Mendelson AS2 Server as Client to send the AS2 Message to Camel AS2.
In Mendelson I have configured 'Content Transfer Encoding:' 'base64' and
'Payload content type:' 'application/EDI-Consent'.
I sent a zip file containing some content items during my tests.
When receiving the file in the processor it was already corrupted and after
saving it to the filesystem the zip file can't be opened.
After debugging the the Camel AS2 module I saw it gets corrupt in
EntityUtil.decode method because the base64 encoded zip file is decoded to a
native zip byte[].
The decoded native zip byte[] then is given as a parameter to a String
Constructor which obviously lets a binary get corrupt.
Here is a screenshot of the Mendelson AS2 Partner Configuation
!image-2025-01-10-15-09-59-096.png|width=629,height=460!
In your provided Unit Tests you have choosen '7bit' content transfer encoding
instead of 'base64' content transfer encoding:
EDI_MESSAGE_CONTENT_TRANSFER_ENCODING = "7bit"
This is a different approach. If you are choosing 'base64' content transfer
encoding the decode method in EntityUtils will run into 'case "base64"' and do
a decode of the zip.
{code:java}
switch (encoding.toLowerCase()) {
case "base64":
return Base64.decode(data);
case "quoted-printable":
return QuotedPrintableCodec.decodeQuotedPrintable(data);
case "binary":
case "7bit":
case "8bit":
// Identity encoding
return data;
default:
throw new CamelException("Unknown encoding: " + encoding);
} {code}
Possibly this helps for the reproduction.
> camel-as2: Binary files get corrupt when using 'base64' content transfer
> encoding
> ---------------------------------------------------------------------------------
>
> Key: CAMEL-21505
> URL: https://issues.apache.org/jira/browse/CAMEL-21505
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
> Affects Versions: 4.8.1
> Environment: Windows and Docker
> Java 21 Temurin
> Reporter: Meinolf S-D
> Priority: Minor
> Fix For: 4.8.4, 4.10.0
>
> Attachments: image-2024-12-03-12-29-47-487.png,
> image-2025-01-10-15-09-59-096.png
>
>
> Binary files get corrupt when using *base64* content transfer encoding due to
> String assignment of the decoded byte[]
> This can easily be tested sending a .zip file to Camel AS2 listener.
> After some investigation the issue seems to be in the EntityUtil.decode
> method.
> As shown in the screenshot the decoded (binary) byte[] is assigned to a new
> String which result into corrupt date in case of binary content.
> !image-2024-12-03-12-29-47-487.png!
> In addition there are new line characters in the encoded base64 encoded
> String data object.
> In case of using transfer encoding type *binary*
> java.nio.charset.MalformedInputException: Input length = 1 it thrown which
> might be OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
