Our application is written in Java 8, uses glassfish 4.1.1 application-server. Part of the functionality is implemented using WebSockets technology.

On the server side, Websockets are implemented via @ServerEndpoint (If necessary, I can provide the code). The port is not explicitly specified. Googling, it turned out that in this case they use the default port 80 (correct if I am mistaken).

In general, the web application works well, users do not have problems with connecting to it and to web socket.

However, on one of the machines, the web application does not load with the error:

failed to execute 'send' on websocket: Still in CONNECTING state

On that user's machine, Google Chrome is used, so there is no reason to think that web sockets there may not be supported.

What could be the problem? Why does it manifest itself in such a strange form only on one computer (maybe someone else, only I do not know about it)?

Have any ideas? We will be very grateful!

    2 answers 2

    The send method needs to be called only when ws.readyState === 1, this usually occurs after the onopen event.

    ws.onopen = function(){ ws.send({param1:'test'}) }
    • Yes, they have already reached it on their own. However, the problem did not go away. The connection just doesn't go through now. Roughly speaking, readyState does not become == 1. Browser / antivirus / system settings are probably to blame. Are there any ideas? - luxor
    • one
      The problem is obvious in the browser. As far as I remember, WebSocket has several protocols, perhaps the server does not support exactly the protocol that is implemented in this browser. Is the version old? In fact, I came across this only once, and this was one of the old versions of Safari. - Petr Chalov

    In fact, the problem lay in the proxy of the network in which the computer of that user was located. It turned out that we use an unprotected protocol (ws), the proxy server corrects the request headers and thereby spoils it (the request).

    A fairly obvious solution in this situation was the transition from the unprotected (http) to the secure (https) protocol. And, respectively, from ws to wss, if we are talking about websockets.

    Because transmission via a secure protocol is encrypted, the proxy server no longer has the ability to "tweak" the headers and "skips" the request as is. Ultimately, the connection is successfully established.

    In general, many thanks to everyone who showed participation and helped me deal with this problem!