You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Michael Justin (Jira)" <ji...@apache.org> on 2021/12/01 18:01:00 UTC

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

    [ https://issues.apache.org/jira/browse/AMQ-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17451945#comment-17451945 ] 

Michael Justin commented on AMQ-8409:
-------------------------------------

Hi and many thanks!

I see that the patch does not check the Stomp version, only in Stomp 1.2 the CR must be converted to \r and back.

Without checking the protocol version, it would break Stomp 1.1 clients,  which do not convert CR to \r (and back). 

 

> 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: Improvement
>          Components: STOMP
>         Environment: Broker: ActiveMQ 5.16.3
> OS: Windows 10
> Client: own implementation
>            Reporter: Michael Justin
>            Priority: Major
>         Attachments: AMQ-8409.patch, image-2021-11-07-12-04-34-856.png
>
>
> 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 *&#92;&#92;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&#92;&#92;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)