Passing HTTP upgrade request header value to the STOMP plugin

[laurentluce]

I am wondering if the following is currently possible or could be possible with some modifications to the plugins:

• Client adds a custom header to the initial GET upgrade request.
• Custom header value is accessible from the STOMP plugin for this connection. The value can be used during frame handling.

[michaelklishin]

Used how, for example? Propagating headers is possible but how will it be used?

[laurentluce]

@michaelklishin The header value would be used to modify the STOMP send message destination for example.

[michaelklishin]

@laurentluce what's the end goal? Sorry but your idea is not very specific and we cannot implement (or even evaluate) something that's not specific.

[laurentluce]

@michaelklishin The flow would be: Client -> Nginx -> RabbitMQ. In this case, Nginx would be the one adding a custom header to the HTTP GET upgrade request. The client does not know the header value and cannot be trusted to send it. The header value could contain ID information for example. The STOMP plugin then uses the header value to modify the send and subscribe messages.

[michaelklishin]

So you simply want to propagate some headers to STOMP frames? And they will be used by STOMP or Web STOMP consumers?

On 30 ene 2016, at 0:16, Laurent Luce notifications@github.com wrote:

@michaelklishin The flow would be: Client -> Nginx -> RabbitMQ. In this case, Nginx would be the one adding a custom header to the HTTP GET upgrade request. The client does not know the header value and cannot be trusted to send it. The header value could contain ID information for example. The STOMP plugin then uses the header value to modify the send and subscribe messages.

— Reply to this email directly or view it on GitHub.

[laurentluce]

@michaelklishin The first use case I am looking at is to use the header value to complete the message destination sent by the Web STOMP client. The messages sent by the client would be consumed by a Web STOMP consumer.

[michaelklishin]

What exactly does "complete" mean.

We won't be making changes to the plugin to accommodate a single use case. It is currently really easy to reason about what this plugin does.

Propagating headers is one thing; custom routing logic based on headers is a very different one.

On 30 ene 2016, at 0:45, Laurent Luce notifications@github.com wrote:

@michaelklishin The first use case I am looking at is to use the header value to complete the message destination sent by the Web STOMP client. The messages sent by the client would be consumed by a Web STOMP consumer.

— Reply to this email directly or view it on GitHub.

[laurentluce]

@michaelklishin Understood. Custom routing based on HTTP headers is a good way to describe this use case. I am curious to know if passing information from the initial HTTP upgrade request to the STOMP broker is something other people have been asking. In this use case, Nginx does not understand STOMP frames so it can only pass the info at the HTTP layer.

[michaelklishin]

I only recall header propagation being requested once or twice. We could propagate, say, certain X-* headers and then append them to certain STOMP frames. But that is very opinionated/use case-specific.

If you need custom routing that does not fit how STOMP works, you probably want to develop a small bridge service that accepts WebSocket messages and translates them into STOMP frames with the correct destination, for example. Which is effectively reimplementing this plugin for your needs.

Or re-architect your solution to fit how STOMP works (this plugin is nothing more than a "transport bridge" to STOMP). Lets continue this discussion on rabbitmq-users if you have more info to share. Perhaps someone in the community has something to recommend.