Cannot connect to Web-Stomp from behind a proxy when using Google Chrome

[rwil...@scottlogic.co.uk]

(originally reported on GitHub https://github.com/rabbitmq/rabbitmq-web-stomp/issues/10 and referred here)

Possibly a sockjs-erlang issue that affects the plugin.

When connecting from behind a proxy (using sockjs-client restricted to WebSocket transport, or directly using browser's WebSocket), I am unable to connect to Web-Stomp.

When using a proxy, Chrome (v40) will include the "Proxy-Connection: keep-alive" header in WebSocket requests. So the request goes out with that and the required "Connection: Upgrade".

I've seen it with Fiddler and another proxy server that they will rename the Proxy-Connection header to "Connection", causing the request that reaches Web-Stomp/SockJS to have two Connection headers - one with "keep-alive" (first), and another with "Upgrade" (second).

When this is received by the server, it sends a 400 Bad Request response so the WebSocket connection isn't established.

Attempting the same scenario (Chrome, behind a proxy) connecting to a non-Web-Stomp/SockJS works without any problem. I tried a few of the popular WebSocket test pages. The two Connection headers are sent just the same, but it appears that their server side component is smart enough to deal with the conflicting headers.

This looks like the relevant part of sockjs-erlang (I'm not familiar with the language):https://github.com/sockjs/sockjs-erlang/blob/66ea7f3fabac8d0f66aa88a354577b7c6be8fe9a/src/sockjs_handler.erl#L66

[Michael Klishin]

On 30 January 2015 at 19:03:45, rwil...@scottlogic.co.uk (rwil...@scottlogic.co.uk) wrote:
> Possibly a sockjs-erlang issue that affects the plugin.
>
> When connecting from behind a proxy (using sockjs-client restricted
> to WebSocket transport, or directly using browser's WebSocket),
> I am unable to connect to Web-Stomp.
>
> When using a proxy, Chrome (v40) will include the "Proxy-Connection:
> keep-alive" header in WebSocket requests. So the request goes
> out with that and the required "Connection: Upgrade".
>
> I've seen it with Fiddler and another proxy server that they will
> rename the Proxy-Connection header to "Connection", causing
> the request that reaches Web-Stomp/SockJS to have two Connection
> headers - one with "keep-alive" (first), and another with "Upgrade"
> (second).
>
> When this is received by the server, it sends a 400 Bad Request
> response so the WebSocket connection isn't established.
>
> Attempting the same scenario (Chrome, behind a proxy) connecting
> to a non-Web-Stomp/SockJS works without any problem. I tried
> a few of the popular WebSocket test pages. The two Connection
> headers are sent just the same, but it appears that their server
> side component is smart enough to deal with the conflicting headers.

This is likely an issue with SockJS or its server part (which badly needs upgrading).

What kind of proxy do you use? Is there an easy way for us to re-create relevant parts of your environment
to  reproduce the issue?
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[rwil...@scottlogic.co.uk]

The issue was first noticed when running the Fiddler2 local proxy inspector and can be reliably reproduced and observed using it by just having it running (and therefore acting as a proxy) while attempting to connect to Web-Stomp.

We've also seen it with another proxy server, but haven't been able to establish yet from the user what type of proxy he was using.

All we've done to our inherited configuration is enable the plugin.

The version of RabbitMQ is RabbitMQ 3.4.2, Erlang 17.3.2.

[Michael Klishin]

On 30 January 2015 at 19:17:22, rwil...@scottlogic.co.uk (rwil...@scottlogic.co.uk) wrote:
> The issue was first noticed when running the Fiddler2 local
> proxy inspector and can be reliably reproduced and observed
> using it by just having it running (and therefore acting as a proxy)
> while attempting to connect to Web-Stomp.
>
> We've also seen it with another proxy server, but haven't been
> able to establish yet from the user what type of proxy he was using.
>
> All we've done to our inherited configuration is enable the plugin.
>
> The version of RabbitMQ is RabbitMQ 3.4.2, Erlang 17.3.2.

Cheers.

WebSTOMP hasn't been getting much attention in a while and we are quite stretched
with a team of 3 but we'll see what we can do. Bug filed.

[rwil...@scottlogic.co.uk]

Further to this, we've observed that Fiddler and our user's unknown proxy, do not rename the Proxy-Connection header when connecting over secure web sockets. So this isn't an immediate problem for us as we use secure production.