[ARTEMIS-234] STOMP 1.0 text message frames must not have a content-length header

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.1.0, 1.2.0, 1.3.0
• Fix Version/s: 1.4.0
• Component/s: STOMP

Environment

Windows 8, Java 8

• Assignee: Justin Bertram
• Reporter: Michael Justin
• Created: 26/Sep/15 14:40
• Updated: 03/Nov/16 20:41
• Resolved: 20/Jul/16 14:05

Description

In Artemis 1.0.0, distinction between text and binary message was possible based on the content-length header as documented: "A Stomp client can check the presence of the content-length header to determine the type of the message body (String or bytes)."

With Artemis 1.1.0 the MESSAGE frame always includes the content-length header, so that the distiction is not possible:

SEND
destination:jms.queue.ExampleQueue

Test message

received:

MESSAGE
subscription:

{B806BF9D-B761-419C-8645-BBE3AED5CAF8}

message-id:2147488964
destination:jms.queue.ExampleQueue
expires:0
redelivered:false
priority:4
timestamp:1443278118819
content-length:12

Test message

Additional information: the documented behaviour is also implemented in Apache ActiveMQ:

"Stomp is a very simple protocol - that's part of the beauty of it! As such, it does not have knowledge of JMS messages such as TextMessages or BytesMessages. The protocol does however support a content-length header. To provide more robust interaction between Stomp and JMS clients, ActiveMQ keys off of the inclusion of this header to determine what message type to create when sending from Stomp to JMS."

Fixing this issue would increase the compatibility of Artemis with ActiveMQ

Issue Links

• relates to: ARTEMIS-235 Map content-type to message type on Stomp
• links to: GitHub Pull Request #646