[
https://issues.apache.org/jira/browse/AMQ-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Justin updated AMQ-8409:
--------------------------------
Description:
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.
was:
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.
> 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: 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
> *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)
