Missing header Sec-WebSocket-Protocol during handshake

[JSteunou]

It only happens when using new native websocket endpoint with Chrome which is stricter than Firefox (dont know who is right and dont know about the other browsers)

WebSocket connection to 'ws://localhost:15674/ws' failed: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received

Using RMQ 3.6.1 chrome 49 firefox 45

[essen]

That's weird, that header is for selecting protocols implemented on top of Websocket. Browsers aren't supposed to set it on their own. I'll look into it.

[JSteunou]

It does not set it, Chrome complains about the header is missing in the response. Sorry if I explained it poorly. To sum it up:

• request contains header sec-websocket-protocol: v10.stomp, v11.stomp
• response from rabbitmq web-stomp does not contain sec-websocket-protocol
• firefox is fine about it, chrome not so much

[JSteunou]

more intel: if I do not set sec-websocket-protocol in the request, still nothing in the response but at least Chrome does not complain about inconsistency and it works.

[essen]

Yes I understood. Basically the way this header works is that if it's no set in the request, the server doesn't send it in the response; and if it's set in the request, the server must send it in the response with the selected protocol (and otherwise the connection fails). So Chrome is correct in failing.

Wondering why you set this header in the request though? Do we have something in RabbitMQ that says it's needed? We could select the first protocol in the request's header to make it work but it is meaningless if we don't follow that protocol.

[JSteunou]

https://github.com/jmesnil/stomp-websocket set protocols by default. It's a good practice, I would prefer the server check if one on the list match one in its list and send back the best match. Maybe not the first, but the upper version of the protocol.

And if you are not sure about sending it back because you might not follow the protocol, maybe that's another issue ;)

[essen]

I'm fine with improving the protocol header handling. I'll need to check what other clients are sending. Thanks for the feedback!

[JSteunou]

Thank you!

[essen]

I have pushed a fix for this (see PRs above). Please try and report! :-)

We explicitly support v12.stomp, v11.stomp and v10.stomp, as those three are registered at IANA.

[michaelklishin]

@essen this issue is for 3.6.x but both PRs are submitted against master.

[essen]

Sorry, looks like I make that mistake often...

[essen]

Done.

[michaelklishin]

@JSteunou email me at michael in RabbitMQ domain and let me know what package type you need for testing. I'll send one over.

[JSteunou]

thank you, will do that!

[JSteunou]

@essen tested, approved ;) @michaelklishin had a little warning about socat package not being installed, except that all went fine

Thank you both, great job!

[michaelklishin]

@JSteunou we are aware that installing with dpkg will emit a warning. socat is not essential to RabbitMQ operation.

Thanks for the update.

[essen]

Thanks!

[lreisoliveira]

Chrome or Firefox not work

Client from here: https://raw.github.com/jmesnil/stomp-websocket/master/lib/stomp.min.js

Stomp.client('ws://localhost:3000/websocket', ['v10.stomp', 'v11.stomp', 'v12.stomp']);

The response

WebSocket connection to 'ws://localhost:3000/websocket' failed: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received

Why?

[JSteunou]

Are you using the latest RMQ?

[michaelklishin]

@lreisoliveira please post questions to rabbitmq-users or Stack Overflow. RabbitMQ uses GitHub issues for specific actionable items engineers can work on, not questions. This specific issue was fixed in the 3.6.2 release cycle as the milestone suggests. Thank you.

[lreisoliveira]

Thanks