tracker issue : CF-3645217

select a category, or use search below
(searches all categories and all time range)
Title:

Sec-WebSocket-Protocol

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/CannotReproduce

Reporter/Name(from Bugbase): Matthew Bram / Matthew Bram (Matthew Bram)

Created: 10/02/2013

Components: Web Socket

Versions: 10.0

Failure Type:

Found In Build/Fixed In Build: Final /

Priority/Frequency: Major / Most users will encounter

Locale/System: English / Mac 10.7 64-bit

Vote Count: 0

Problem Description: 
In Chrome 30, I'm getting this error in the console: 
WebSocket connection to 'ws://127.0.0.1:8585/cfusion' failed: Error during WebSocket handshake: Sec-WebSocket-Protocol mismatch
Does not happen in Chrome 29 or in other main browsers. From what I've read via google search, removing this header fixes the issue in PHP and Node implementations. 

Steps to Reproduce:

Actual Result:

Expected Result:

Any Workarounds:
Chrome 30 may be throwing exception because the client is not initializing the header first. I have not verified this with wireshark.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3645217

Deployment Phase:	Release Candidate

External Customer Info:
External Company:  
External Customer Name: mbram
External Customer Email:  
External Test Config: My Hardware and Environment details:

MacBook Pro Development environment. localhost:8500, ws://127.0.0.1:8585

Attachments:

  1. October 03, 2013 00:00:00: 1_Switching_Protocols.txt
  2. October 03, 2013 00:00:00: 2_ClientGet.txt

Comments:

I understand the WS specification is changing. Please issue update to address! Thank you.
Comment by External U.
14347 | October 02, 2013 12:22:22 PM GMT
I have done some wireshark captures to identify the headers passing between the client and the server. It appears that the 'Sec-WebSocket-Protocol' key is being sent to the server in the 'GET /cfusion HTTP/1.1' request. However, on the 'HTTP/1.1 101 Switching Protocols' response back from the server, the 'WebSocket-Protocol' key is returned instead of the exact key provided by the client. It appears that Chrome has adopted a strict compliance to the RFC6455 Sec 4.2.2, Par 5.5, which provides for the optional use of 'Sec-WebSocket-Protocol' and not 'WebSocket-Protocol.' I have provided the captures from Chrome 30 to demonstrate.
Comment by External U.
14348 | October 03, 2013 01:43:22 AM GMT
Hello, I have been trying to reproduce this issue but unable to do so. Would you mind sharing the ColdFusion build number which you are using?
Comment by Nimit S.
14349 | October 08, 2013 01:51:07 AM GMT
Developer 10,0,11,285437
Comment by External U.
14350 | October 08, 2013 11:53:38 AM GMT
I have also verified that the issue is showing up in the Windows 7 version of Chrome 30. I had Chrome 29 working with websockets and then when I upgraded to Chrome 30 it now fails. Everything is also working correctly in IE10. Thank you...
Comment by External U.
14351 | October 10, 2013 12:42:47 PM GMT
I know I'm being impatient here! However, this outage is really impacting us. Is there any update on this issue? Thank you...Matt Bram
Comment by External U.
14352 | October 21, 2013 11:28:44 AM GMT
Issue persisting in Chrome 31
Comment by External U.
14353 | November 20, 2013 02:53:54 PM GMT
Hi Matt, I tried reproducing this issue with CF10 update 11, but it seems to be working fine at our end. I even tried it with Chrome 31. Our support team tried contacting you over email. Can you please work with them so that we can look into it on priority? Regards, Nimit
Comment by Nimit S.
14354 | December 19, 2013 07:12:55 AM GMT
I have traced this issue down to the super classes used by the apache container. I will test to see if this is showing up in a different JVM.
Comment by External U.
14355 | December 19, 2013 09:59:35 AM GMT
Issue Fixed******* In cfwebsocketCore.js at 'this.wsConnection=new WebSocket(_20d,"json");' the RFC states that only the uri string literal should be passed tot he WebSocket constructor. When the second string parameter, "json" was removed, all instances under all browsers became active. Verified on production solution 3/13/2014 by Matt Bram Per the W3, URL: http://www.w3.org/TR/2009/WD-websockets-20090423/ The WebSocket constructor takes one parameter, a string containing the URL of the server to be connected to. **** Please mark this as verified *****
Comment by External U.
14356 | March 14, 2014 02:07:00 PM GMT
We use the suggested constructor only which fixed his problem. May be he is using an old CF version where the Websocket constructor is being called with additional param. The issue is no longer valid. Please test and close it.
Comment by Awdhesh K.
14357 | November 26, 2014 12:22:59 AM GMT