michaelklishin
commented
9 years ago This repository is a mirror. Please post questions to rabbitmq-users.
Closed rwilliams-scottlogic closed 9 years ago
michaelklishin
commented
9 years ago This repository is a mirror. Please post questions to rabbitmq-users.
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