Ensure server messages contain a destination matching that of the original subscription for user destinations [SPR-11423] #16050
Scenario: Register a user-specific queue/topic. Send a message. Review the response.
The portfolio example works because the destination resolution is performed via subscription id. Some implementations require queue destination string matching. There is an accommodation called 'glob' matching for situations like how Spring is handling the user uniqueness, however the fact that the response frames truncate the /user/ causes an implementation like Dart-Stomp to not actually resolve.
I'm not sure if this is a bug or improvement request. I'm also not sure if you would consider it a bug in dart-stomp or a bug in Spring. Uncertain if other implementations of Stomp use only subscription-id or also rely on path matching.
By way of example:
Register for subscription to: /user/queue/socket/responses
Understandably, Spring uniquifies this value so a response comes down:
If Spring returned '/user/queue/socket/responses-userh9vfizvw' instead of '/queue/socket/responses-userh9vfizvw' and the match used Glob matching then this would all work just fine. The Glob matching is akin to /user/queue/socket/responses*
However the /user is taken off and thus fails. I have worked around this by forking the dart-stomp implementation and changing the match to use subscription-id but this seems like a less flexible long term approach.
The text was updated successfully, but these errors were encountered:
Rossen Stoyanchev commented
The STOMP spec does say the subscription id is unique within a single connection:
In theory it should be sufficient to match a server MESSAGE frame to a client-side handler.
That said it might be more intuitive if we fixed this on our end to make sure messages received on a user destination have a destination that matches the original destination of the subscription. That way we are not leaking what is an implementation detail of how user destinations are translated on the server side.