Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure server messages contain a destination matching that of the original subscription for user destinations [SPR-11423] #16050

Closed
spring-projects-issues opened this issue Feb 12, 2014 · 2 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Feb 12, 2014

Chris Mathias opened SPR-11423 and commented

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

["SUBSCRIBE\nid:1\ndestination:/user/queue/socket/responses\n\n\u0000"...ommitted

Understandably, Spring uniquifies this value so a response comes down:

a["MESSAGE\ncontent-type:application/json;charset=UTF-8\nsubscription:1\nmessage-id:h9vfizvw-0\ndestination:/queue/socket/responses-userh9vfizvw\ncontent-length:2289...ommitted

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.


Affects: 4.0.1

Reference URL: https://github.com/revelfire/stomp/commit/3dcfbefc2ec218fc79e77445c1acabd2eed5315a

Issue Links:

  • #16271 SUBSCRIBE response message should match the original message destination

Referenced from: commits 1200755, 443fb8e, 32e5f57

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 13, 2014

Rossen Stoyanchev commented

The STOMP spec does say the subscription id is unique within a single connection:

"Since a single connection can have multiple open subscriptions with a server, an id header MUST be included in the frame to uniquely identify the subscription. The id header allows the client and server to relate subsequent MESSAGE or UNSUBSCRIBE frames to the original subscription."

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.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 13, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants