activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Ländle (JIRA) <j...@apache.org>
Subject [jira] [Commented] (AMQ-3838) Stomp-Transport: Multiple error frames generated
Date Tue, 22 May 2012 09:12:41 GMT

    [ 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

       

Mime
View raw message