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

Claus Ibsen updated CAMEL-21327:
--------------------------------
    Fix Version/s: 4.x
                       (was: 4.10.0)

> 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)

Reply via email to