Sec-WebSocket-Protocol Issue in Chrome30

[mbram]

Hello Friends,

I am in development of a web application that uses the new ColdFusion HTML5 websockets technology. I recently upgraded my MacBook Pro to Chrome30 from 29 and, what do you know, the websockets magically stopped working! After Google-ing for some context on the issue, it appears that Google has made changes to the way they implement the Sec-WebSocket-Protocol parameter negotiated during the socket setup. It turns out that the client (ColdFusion's Tag in JS) is sending the 'GET /cfusion HTTP/1.1' request with the Sec-WebSocket-Protocol key, which complies with the optional parameter defined in RFC6455. However, when the server responds back to the client with the '...Switching Protocols' response, it is passing back 'WebSocket-Protocol.' All of the other paramaters do include the 'Sec-' prefix, which does adhere to the RFC.

From what I have read, the failure, "WebSocket connection to ws://localhost:8585/cfusion' failed: Error during WebSocket handshake: Sec-WebSocket-Protocol mismatch"is either a result of either two things: 1) Chrome is no longer following the RFC6455 4.2.2 standard, or 2). They are now adhering strictly to the RFC and the ColdFusion server's non-compliance of the parameter is breaking the handshake.

I have read that some developers whom are implementing WS on Node.js and PHP, are completely removing the Sec-WebSocket-Protocol from the header to solve the problem. Luckily, I am still in development and have not experienced an outage because of the mixup. I have reported the issue to the Bug Tracking system, ID: 3645217.

If you have also run into the issue, please make a note on the bug to help escalate to our friends at Adobe. They are working hard to make ColdFusion one of the best server-side technolgies around, but we need to get their attention on this one as it is a non-starter, web-socket killer!

Regards,

Matt Bram

Message was edited by: mbram - Added link to bug.

[James22s22]

I've encountered this same bug.  Man, what is with October and software time-bombs!  There was just a time-bomb with Visual Studio and SSDT that went off on Oct 6th because of some bug involving an expired certificate, making it impossible to install stuff without temporarily setting back the system clock: http://social.msdn.microsoft.com/Forums/sqlserver/en-US/51ef983f-1f07-41b4-bad4-3541e93d4647/known-i...

Anyway, I just moved everything to a new server and thought I had something configured wrong, until I realized I could connect from my desktop's browser, but not the one on the server.

In fact, it's Chrome 30 that seems to be the culprit, because while I can connect fine on Chrome 29, I can no longer connect on Chrome 30. Of course, this is a JavaScript WebSocket issue, and I'm running IIS 8, so I think this is strictly a Chrome issue, independent of ColdFusion or IIS 8 (since I'm using IIS8 and you're using ColdFusion and we're both experiencing the problem).

The error I get is "WebSocket connection to 'wss://xxx.xxx.xxx.xxx/ws.ashx' failed: Error during WebSocket handshake: Sec-WebSocket-Protocol mismatch".

[mbram]

*** Issue Resolved ***

I was completely stumped. Desperate. The thought of re-writing 10K lines made me sick. Then, I stumbled on pure gold. I was visiting https://groups.google.com/forum/#!topic/chicagoboss/M4fTHZN6qNE and I found an entry about the change in expected parameters in the WebSocket constructor in javascritp from old browsers to new. Adobe was adding a second parameter, "json" to the constructor and Chrome did not like it as the CF server was not returning the same item. I removed the second param and what do you know, it came alive. People are chatting and the world makes sense! Just wanted to give you an update.

I am using an adapted version of the CF javascript files found in the AJAX folder on the server. However, if you run into this problem, simply go into the cfwebsocketCore.js file and look for the line: this.wsConnection=new WebSocket(_20d,"json"); The _20d is the URL string of the server. Remove the "json" parameter from the constructor. This should bring it up. If you are interested, go to the W3 site at http://www.w3.org/TR/2009/WD-websockets-20090423/ and notice that the WebSocket constructor takes one parapeter - the URI string!

Regards...Matt Bram

[BKBK]

Hi Matt,

Nice to hear you found your answer. To assist others, please kindly mark it as 'Correct'. Thanks.