[
https://issues.apache.org/jira/browse/AMQ-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280827#comment-13280827
]
Andreas Ländle commented on AMQ-3838:
-------------------------------------
Well, I also recognized that the connection is closed in this case. However,
please take the following into account - the client is already authenticated is
this case, so I'll guess there may exist better approaches for DoS than just
sending to a queue where the client is not authorized for. And since a STOMP
client has no possibility to ask if it is authorized to write/read a specified
queue (or even if it exists) it might be quite hard for the client to decide if
it is worth to try to send the message again - because for that it has to parse
the message of the error frame - and it would be very hard because if a
subsequent send message to a valid destination still returns a error frame so
that the client might get confused (at least it also has to consider receipt
identifiers).
Furthermore I believe that the current behavior of the broker didn't meet the
intention of the stomp protocol - but the specification is very unclear about
the way how error frames should be used. But I understand STOMP more like a
very simple QUESTION/ANSWER model. So maybe it is o.k. to abort the connection
for DoS reasons (any good client should be able to handle connection
interruptions), but I find it very hard to refuse any further communication
after the client made a mistake (especially if the client sends totally
unrelated commands like e.g. a DISCONNECT) - but that is just my interpretation!
For me it doesn't seem to be hard to work around this issue, because I just
send one message in one transaction and if it fails I destroy the connection
anyway. So I have no problems with subsequent messages and I just hope that it
doesn't bring side effects if I didn't try to re-send messages which are
answered with an ERROR frame (so I hope there is no scenario where these frames
are send because of only a temporary broker problem).
Nonetheless thanks a lot for your explanations, and by implication your time,
Timothy. And don't get me wrong - ActiveMQ is really a great product - I just
was surprised that after migration of our test system some of my tests fail
because of this behavioral change. But now I feel assured and I will just apply
the mentioned workaround and update our live system...
> Stomp-Transport: Multiple error frames generated
> ------------------------------------------------
>
> Key: AMQ-3838
> URL: https://issues.apache.org/jira/browse/AMQ-3838
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.6.0
> Environment: Win7Enterprise;Java7;ActiveMQ 5.6
> Reporter: Andreas Ländle
> Labels: activemq, stomp, transport
> Attachments: ActiveMq55.txt, ActiveMq56.png, ActiveMq56.txt,
> Reproduce_AMQ3838_StompTest.java.patch
>
>
> I tried to update ActiveMQ 5.5 to 5.6 and discovered a behavioral change if
> you try to send a message to an invalid queue with stomp. While v5.5 just
> rejects the message and returns one ERROR frame, v5.6 sends multiple error
> frames. I'll attach two network captures showing the conversation between
> client/server in 5.5 and 5.6 - in 5.6 you'll see the repeated error frames.
> Please let me know if I was unclear of if you need more information. Thanks
> in advance for any assistance or hint that will help me to get around this
> problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
