tracker issue : CF-4154216

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

Web Socket Frame Size Error in Google Chrome and IE

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): ryan whatever / ryan whatever (ryan whatever)

Created: 05/17/2016

Components: Web Socket

Versions: 10.0

Failure Type: Non Functioning

Found In Build/Fixed In Build: Final /

Priority/Frequency: Critical / All users will encounter

Locale/System: English / Win All

Vote Count: 0

Listed in the version 2016.0.03.300466 Issues Fixed doc 
Problem Description:I am publishing data over a Websockets channel every 2 seconds, the file is an array of data which has been converted to JSON. Everything works perfectly on all browsers (FireFox, IE, Chrome), however if I increase the size of the data (to over 65KB) then I get errors in Chrome and IE but FireFox still works fine. The error message in Chrome is : Websocket connecttion to 'ws://mywebsite.com' failed: Invalid frame header Uncaught TypeError: Cannot set property 'readyState' of undefined Basically, form what I have been able to gather (if I am correct) is that Coldfusion is incorrectly stating the frame size with the larger data and FireFox is more forgiving of this that Chrome or IE.

Steps to Reproduce: Enable Web Sockets, add a channel in Application.cfc, generate an array of more than 65K, convert it to JSON format, publish it on the Web Socket channel - you will note the packet is received and parseable in FireFox, yet comes up with error in Chrome or IE

Actual Result:

Expected Result:

Any Workarounds:

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

Watson Bug ID:	4154216

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

Attachments:

  1. May 18, 2016 00:00:00: 1_Error_Recreation_Files.zip
  2. May 27, 2016 00:00:00: 2_websockets_screenshot.png
  3. May 27, 2016 00:00:00: 3_caching_screenshot.png
  4. May 27, 2016 00:00:00: 4_serversettings_.pdf

Comments:

Any hot fix for this will be greatly appreciated !
Comment by External U.
2769 | May 17, 2016 08:12:55 PM GMT
Hi, Can you please share screenshots for Caching, WebSockets and, Settings Summary present in your ColdFusion Administrator page? This will help us in identifying and fixing the issue ASAP.
Comment by Kailash B.
2770 | May 25, 2016 04:41:46 AM GMT
Hi.. Thank you for taking the time to look at this bug. I have attached the files that you have requested. If you need anything else, please let me know. I can also confirm that the error also happens on CF11 and CF 2016. The guys at Hostek had a look at it and seem to think the problem may arise due to the fact that CF is using an outdated (4 years old) version of Netty.. Thanks.
Comment by External U.
2771 | May 27, 2016 01:28:50 AM GMT
The issue was with Payload length set in websocket frame. Instead of using 8 bytes for payload size more than 65535, we were using it for values more than 32267. Chrome was rejecting any packet of size 32267-65535 as it performs strict checks on headers whereas firefox was just ignoring it.
Comment by Chinoy G.
2772 | May 31, 2016 06:44:35 AM GMT
That is fantastic that you have tracked the error down! Do you think that you may be able to provide a hot-fix for the issue? This would be extremely helpful as I am pretty much stuck with my applications development until I can get this working.. Thanks again for the help.
Comment by External U.
2773 | May 31, 2016 03:54:33 PM GMT
Hi, You will be provided a fix from our support team. Please send a mail to cfinstal@adobe.com citing this bug ID and telling that you need a patch for this particular fix.
Comment by Kailash B.
2774 | May 31, 2016 11:52:41 PM GMT
Hello Adobe Support Team, Thank you so much for providing a fix to this bug, and so quickly! Your support team are really fantastic and your timely assistance has been much appreciated. I can confirm that everything now works as expected. Thanks, Ryan.
Comment by External U.
2775 | June 02, 2016 10:53:58 PM GMT