41

I've been implementing a WebSocket with JavaScript and I have this one problem:
The endpoint that my web-application is connected to doesn't send back a close control frame when I'm sending it one.

This isn't that bad because browsers close the WebSocket connection after a while.

But a few things to notice are:

  • Browsers do only allow a specific amount of WebSockets to be connected at the same time.

  • When refreshing the web-application a new WebSocket is created

This causes the problem on IE:
When refreshing the web-application more than 6 times, a WebSocket connection cannot be made.

It seems like IE doesn't "delete" the WebSockets if they haven't been closed cleanly. And what's odd is that the amount of web sockets never seems to decrease by refreshing or just by waiting.

Only by closing the browser window, or the tab resets the number of WebSockets to 0.


I've done some researching and this is what I've found out:

Browsers do only support a specific amount of WebSockets to be connected at the same time.

IE supports 6 websockets to be connected [link]

Chrome supports 255 websockets to be connected [link].

And socket.onclose() isn't triggered when you do socket.close(), it is called when the endpoint responses with a close message. [link]

IE waits 15 seconds for the endpoint to send the close message [link].

Chrome waits for 60s for the responding message [Sorry, no link for this, found this out by testing].

If no response message is received, the browser closes the WebSocket connection and a TimeoutError should occur.

Please correct me if I'm wrong :)

I've tried to use unbeforeload to disconnect from the endpoint in hope that the browser would close the connection after a while, but with no luck. [link].
It can also be the cause of that IE aren't able to do request inside the unbeforeload function [link].

Question:

  1. Is there any way to reset the number of WebSockets that are connected in the browser to the endpoint with JavaScript?
  2. Is there a way to disconnect a WebSocket from the endpoint immediately without closing the connection cleanly?
  3. Is the only way to get this to work to inform the ones who host their endpoint make some changes so they do send a closing frame back?
  4. Is there anything I've misunderstood or that I could try to get this to work?

Here is (in my opinion) good documentation about the WebSocket protocols if somebody would like to read more about it [link1] [link2].

UPDATE:

Only by refreshing the web-application on IE the WebSockets don't get destroyed.
If you navigate between pages in the web-application a new WebSocket will be made but the last WebSocket will get destroyed.

Sinandro
  • 1,621
  • 1
  • 17
  • 27
OuuGiii
  • 885
  • 1
  • 8
  • 26
  • Did you find a solution for your problem? – Mikhail Chibel Mar 07 '19 at 01:17
  • 1
    @MikhailChibel I haven't found an alternate solution. I think that the best way is to inform the ones who have created the WebSocket server that they should handle closing events and send back a closing frame when requesting for one. In this way, the WebSocket connection will close much faster and there will not be any Websockets connections hanging around waiting for a timeout error to occur. – OuuGiii Mar 25 '19 at 10:25
  • @OuuGiii have you tried emulating the onclose yourself? essentially tricking IE to think the server has responded and the socket closes IE side. – Deckerz Jun 10 '19 at 13:28
  • 1
    @Deckerz Actually no, I haven't. could you provide an example or a link on how to doing that? And I have fixed my issue by contacting the ones who made the WebSocket server that they don't respond to close messages and they have fixed the problem. – OuuGiii Jun 11 '19 at 07:09
  • 2
    This question is related to: https://stackoverflow.com/questions/4812686/closing-websocket-correctly-html5-javascript – filipe Jun 12 '19 at 18:07
  • 4
    You should think about if you want to support an outdated browser. – Vincent Hoch-Drei Jun 13 '19 at 11:28
  • Found similar problem in C# PureWebSockets - did not care (https://github.com/Coinigy/PureWebSockets/issues/14), so I had to do complete rewrite - there were no Close messages at all. My PWS is here in case it can help: https://github.com/eltomjan/PureWebSockets/commits/master – Tom Jun 17 '19 at 12:54
  • @OuuGiii not `window.onbeforeunload` but use `beforeunload`. – ABC Nov 25 '19 at 04:16

2 Answers2

1

If it is just an edge case problem, then using a http fallback might be your only option. I guess you already do this for proxy servers that block socket connection away.

David Bradshaw
  • 10,116
  • 3
  • 33
  • 61
  • I do understand the concept of using a fallback http connection for the web-socket connection.. if you can please collaborate how do you plan to close the web-socket connection (from the fallback) when the entire page is being destroyed – ymz Dec 17 '19 at 07:14
  • If this doesn’t happen much, I would just leave it to time out and use the fall back in the mean time. Retry the connect once a minute to see when you can upgrade back to using the websocket. – David Bradshaw Dec 18 '19 at 18:39
0

There is just 1 idea to verify (unconfirmed). Unfortunately, don't have access to IE to verify.

Application may open websocket connection in WebWorker/iFrame. During page refresh, "websocket connection scope" will be deleted, and connection is freed

EXPLANATION

This content from the question body:

Only by refreshing the web-application on IE the WebSockets don't get destroyed. If you navigate between pages in the web-application a new WebSocket will be made but the last WebSocket will get destroyed.

Says that Websocket connection is not destroyed ONLY when page refreshes. During normal navigation, everything is OK.

So, if websocket connection is opened within other scope which will be deleted during page reload, then hopefully connection will be destroyed.

Andrii Muzalevskyi
  • 2,997
  • 13
  • 18
  • 1
    Well... it does sounds reasonable how about https://www.browserling.com/internet-explorer-testing? you can upload your solution and test it on an old IE (remotely) – ymz Dec 23 '19 at 12:48