Closed michaelJustin closed 2 years ago
It seems the other character transformations are not applied either. (source in class StompFrameMessage). Maybe I can write a fix (at least a draft) however the StompFrameMessage does not contain a reference to the Stomp protocol version of the current connection. Injecting it would be quite invasive.
https://eclipse-ee4j.github.io/openmq/guides/mq-tech-over/brokers.html#gjdmw refers to http://stomp.codehaus.org. https://eclipse-ee4j.github.io/openmq/guides/mq-admin-guide/bridge-services.html#gjmnu refers to http://docs.codehaus.org/display/STOMP/Stomp+JMS, which then links to - something like - http://web.archive.org/web/20150520203728/https://docs.codehaus.org/display/STOMP/Protocol which is 1.0. So I think this is what is supported.
Thus I'm not sure if there is workaround or fix needed here, as I can't see a bug (now). It should rather be treated as new feature(s) to support newer STOMPs I guess. (But that's just naming.)
Please submit any PR you like. If StompFrameMessage
needs to be refactored - feel free to do so in first, separate step.
Thanks for the pointers, @pzygielo, I will prepare a PR. My favourite location to store the negotiated Stomp protocol version would be the StompFrameMessageFactory. This will cause very little code changes.
Are there any special standards I have to follow for the PR?
I have submitted PR #1525 for issue #1524. My ECA, which I signed yesterday, is not approved yet. Maybe this was caused by using my 'anonymous' info@...' email address. I have already changed this in my GitHub profile but the PR still indicates the error.
Regarding 1.2 support, in the Stomp protocol negotiation, Stomp 1.0 and 1.2 are handled as supported (in method getSupportedVersions() for the regular StompProtocolHandlerImpl). I have not further checked the WebSocket StompProtocolHandlerImpl, but it seems it supports only Stomp 1.2 as this is the only version returned by getSupportedVersions().
Most parts of Stomp 1.2 seem to be already implemented according to the specification. The methods which encode / decode Stomp frame header do not apply the escape / unescape. I will create a new issue soon.
Apparently I was wrong, and some support for STOMP 1.1, 1.2 was delivered in MQ5.1.1_B02.
I have created #1534, I suggest to close this issue (#1522) as it is covered with the new issue.
The Stomp 1.1 and 1.2 spec contains a formal (BNF) spec of allowed header octets:
A colon character must be escaped/un-escaped using \c (see section "Value Encoding"):
https://stomp.github.io/stomp-specification-1.2.html
In the stomp bridge, this transformation seems to be missing, which causes errors for example for ACK frames and for temporary queue destinations.
Example for ACK: the server sends a MESSAGE frame with the ack and the message-id headers with no colon escaping:
Example for temporary queues: the broker sends a MESSAGE frame with the reply-to and the message-id headers with no colon escaping:
Note: the issue only exists with clients which use Stomp protocol above 1.0, so the workaround is to stay on Stomp 1.0.