[
https://issues.apache.org/jira/browse/CAMEL-21327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-21327.
---------------------------------
Resolution: Duplicate
> Camel-AS2 Receiver Application Fails for LF-Terminated Line Separator
> ---------------------------------------------------------------------
>
> Key: CAMEL-21327
> URL: https://issues.apache.org/jira/browse/CAMEL-21327
> Project: Camel
> Issue Type: Improvement
> Components: camel-as2
> Affects Versions: 4.5.0
> Reporter: RAVI
> Priority: Minor
> Fix For: 4.x
>
> Attachments: CanonicalOutputStream.java
>
>
> Hi Team,
> We are working on a POC using the Camel-AS2 project (version 4.5.0) to
> establish communication with OpenText/Boomi, as both tools utilize the AS2
> protocol. Our goal is to eventually extend this setup for communication with
> trading partners.
> In our scenario, we have an application acting as a Camel-AS2 receiver that
> listens for incoming messages and uses Camel-AS2 for decryption,
> verification, and MDN handling. On the other side, Boomi/OpenText acts as the
> AS2 sender.
> When our Camel-AS2 receiver processes incoming messages, it successfully
> decrypts them but encounters a failure during verification with the error:
> "message-digest attribute value does not match the calculated value." After
> debugging the code, we observed that the "writeTo" method in the
> {{ApplicationEntity}} class utilizes the {{{}CanonicalOutputStream{}}}, which
> forces CRLF line endings as defined here:
>
> java
> Copy code
> {{static {
> newline = new byte[2];
> newline[0] = (byte) '\r';
> newline[1] = (byte) '\n';
> }}}
> While this works fine for messages terminated with CRLF from OpenText, we
> encounter digest calculation errors when handling LF-terminated messages.
> After adjusting the code to accommodate both CRLF and LF line endings, the
> issue was resolved, and we can now process both types of messages
> successfully.
> However, we would prefer not to customize the Camel-AS2 code. Could you
> provide insights or suggest an alternative approach? We’ve noticed that the
> same line-ending standardization exists in the latest version within the
> {{CanonicalOutputStream}} class.
> Thank you for your help.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
