getting the reason why websockets closed with close code 1006

by

Close Code 1006 is a special code that means the connection was closed abnormally (locally) by the browser implementation.

If your browser client reports close code 1006, then you should be looking at the websocket.onerror(evt) event for details.

However, Chrome will rarely report any close code 1006 reasons to the Javascript side. This is likely due to client security rules in the WebSocket spec to prevent abusing WebSocket. (such as using it to scan for open ports on a destination server, or for generating lots of connections for a denial-of-service attack).

Note that Chrome will often report a close code 1006 if there is an error during the HTTP Upgrade to Websocket (this is the step before a WebSocket is technically “connected”). For reasons such as bad authentication or authorization, or bad protocol use (such as requesting a subprotocol, but the server itself doesn’t support that same subprotocol), or even an attempt at talking to a server location that isn’t a WebSocket (such as attempting to connect to ws://images.google.com/)

Fundamentally, if you see a close code 1006, you have a very low level error with WebSocket itself (similar to “Unable to Open File” or “Socket Error”), not really meant for the user, as it points to a low level issue with your code and implementation. Fix your low level issues, and then when you are connected, you can then include more reasonable error codes. You can accomplish this in terms of scope or severity in your project. Example: info and warning level are part of your project’s specific protocol, and don’t cause the connection to terminate. With severe or fatal messages reporting also using your project’s protocol to convey as much detail as you want, and then closing the connection using the limited abilities of the WebSocket close flow.

Be aware that WebSocket close codes are very strictly defined, and the close reason phrase/message cannot exceed 123 characters in length (this is an intentional WebSocket limitation).

But not all is lost, if you are just wanting this information for debugging reasons, the detail of the closure, and its underlying reason is often reported with a fair amount of detail in Chrome’s Javascript console.

More Related Contents:

  1. In what situations would AJAX long/short polling be preferred over HTML5 WebSockets?
  2. What browsers support HTML5 WebSocket API?
  3. Send message to specific client with socket.io and node.js
  4. How to make cross domain request [duplicate]
  5. Check if my website is open in another tab
  6. Do websockets allow for p2p (browser to browser) communication?
  7. How to maintain a WebSockets connection between pages?
  8. Socket.io 1.x: use WebSockets only?
  9. Closing WebSocket correctly (HTML5, Javascript)
  10. How to wait for a WebSocket’s readyState to change
  11. Inspecting WebSocket frames in an undetectable way
  12. Sending message to a specific connected users using webSocket?
  13. How does WebSocket compress messages?
  14. Good beginners tutorial to socket.io? [closed]
  15. Display image from blob using javascript and websockets
  16. For a push notification, is a websocket mandatory?
  17. Cross-domain connection in Socket.IO
  18. Sharing websocket across browser tabs?
  19. Large file upload with WebSocket
  20. Proper way of using React hooks + WebSockets
  21. Handling connection loss with websockets
  22. Do Shared Web Workers persist across a single page reload, link navigation
  23. AngularJS and WebSockets beyond
  24. Websocket API to replace REST API? [closed]
  25. How to talk to UDP sockets with HTML5?
  26. WebSocket on IE10 giving a SecurityError
  27. Using socket.io standalone without node.js
  28. Socket.io – Manual reconnect after client-side disconnect
  29. Accessing partial response using AJAX or WebSockets?
  30. WebSocket: How to automatically reconnect after it dies

Leave a Comment