[jira] [Updated] (AMQ-8409) Unexpected \\r instead of \r in header property in incoming messages

["Jean-Baptiste Onofré (Jira)" <ji...@apache.org>]

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

Jean-Baptiste Onofré updated AMQ-8409:
--------------------------------------
    Issue Type: Bug  (was: Improvement)

> Unexpected \\r instead of \r in header property in incoming messages
> --------------------------------------------------------------------
>
>                 Key: AMQ-8409
>                 URL: https://issues.apache.org/jira/browse/AMQ-8409
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: STOMP
>         Environment: Broker: ActiveMQ 5.16.3
> OS: Windows 10
> Client: own implementation
>            Reporter: Michael Justin
>            Assignee: Jean-Baptiste Onofré
>            Priority: Major
>             Fix For: 5.17.0, 5.16.4
>
>         Attachments: AMQ-8409.patch, image-2021-11-07-12-04-34-856.png
>
>          Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> I tested the Stomp acceptor handling of escape sequences as specified in the 1.2 protocol documentation.
> With ActiveMQ Artemis 2.19.0, all escape sequences are received according to the 1.2 specification:
> !image-2021-11-07-12-04-34-856.png|width=456,height=105!
> [https://stomp.github.io/stomp-specification-1.2.html#Value_Encoding]
>  
> With ActiveMQ "Classic" however, there is a difference: when the escape sequence *\r* is used in SEND frame header values, it will be received as *\\r* in incoming MESSAGE frames.
> h2. Test with Artemis 2.19.0
> The first example uses the Artemis broker. A message with four special escaped characters (backslash, colon, newline and carriage return) is sent to the broker and then received with identical values.
> As you can see in the example, the header property {{*keyr*}} in the outgoing {{SEND}} frame has the value *value\r* and is received as *value\r* in the incoming {{MESSAGE}} frame.
> Unescaped, this is "value" + carriage return
>  
> {noformat}
> CONNECTED
> version:1.2
> session:be014f64
> server:ActiveMQ-Artemis/2.19.0 ActiveMQ Artemis Messaging Engine
>  
> SEND
> destination:queue/TStomp12TestCase.TestEscapes.Q
> keyb:value\\
> keyc:value\c
> keyn:value\n
> keyr:value\r
> content-type:text/plain
>  
> Send:Bytes:112
> SUBSCRIBE
> destination:queue/TStomp12TestCase.TestEscapes.Q
> ack:auto
> id:{13084522-1FEF-4B8A-802A-4656A77784EA}
>  
> MESSAGE
> subscription:{13084522-1FEF-4B8A-802A-4656A77784EA}
> message-id:10737418259
> destination:queue/TStomp12TestCase.TestEscapes.Q
> expires:0
> redelivered:false
> priority:4
> persistent:false
> timestamp:1636280945342
> content-type:text/plain
> keyn:value\n
> keyc:value\c
> keyb:value\\
> keyr:value\r
> {noformat}
>  
> h2. Test with ActiveMQ 5.16.3
> As you can see in the example, the header property {{*keyr*}} in the outgoing {{SEND}} frame has the value *value\r* (as in the first test) but is received as *value\\r* in the incoming {{MESSAGE}} frame. Unescaped, this is not "value" + carriage return, but "value\r".
> {noformat}
> CONNECTED
> server:ActiveMQ/5.16.3
> heart-beat:0,0
> session:ID:DESKTOP-3LKMPLS-49926-1636281770555-3:4
> version:1.2
> SEND
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> keyb:value\\
> keyc:value\c
> keyn:value\n
> keyr:value\r
> content-type:text/plain
> SUBSCRIBE
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> ack:auto
> id:{7316E53E-E7C3-43DC-B2EF-75BCFC09D899}
> MESSAGE
> keyr:value\\r
> expires:0
> destination:/queue/TStomp12TestCase.TestEscapes.Q
> subscription:{7316E53E-E7C3-43DC-B2EF-75BCFC09D899}
> priority:4
> keyb:value\\
> keyc:value\c
> message-id:ID\cDESKTOP-3LKMPLS-49926-1636281770555-3\c4\c-1\c1\c1
> content-type:text/plain
> keyn:value\n
> timestamp:1636281794663
> {noformat}
>  
>  
> So it seems that ActiveMQ Classic performs either an incorrect unescaping on the incoming message, or an incorrect escaping on the outgoing message.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)