it-swarm.com.de

grund dafür, warum websockets mit close-Code 1006 geschlossen werden

Ich möchte, dass der Grund von websockets geschlossen wird, damit ich dem Benutzer die richtige Nachricht zeigen kann.

Ich habe

sok.onerror=function (evt) 
     {//since there is an error, sockets will close so...
       sok.onclose=function(e){
           console.log("WebSocket Error: " , e);}

Der Code ist immer 1006 und der Grund ist immer "". Aber ich möchte verschiedene abschließende Gründe unterscheiden.

Beispielsweise gibt die Befehlszeile einen Fehlergrund an: "Sie können das nicht löschen, weil die Datenbank Sie nicht zulässt". In der Chrome-Konsole ist der Grund jedoch immer noch "". 

Gibt es eine andere Möglichkeit, verschiedene Schließgründe zu unterscheiden?

52
slevin

Close Code 1006 ist ein spezieller Code, der besagt, dass die Verbindung von der Browser-Implementierung abnormal (lokal) getrennt wurde.

Wenn Ihr Browser-Client einen Schließcode 1006 meldet, sollten Sie das Ereignis websocket.onerror(evt) auf Details überprüfen.

Chrome gibt jedoch nur wenige nahe liegende 1006-Gründe an die Javascript-Seite weiter. Dies ist wahrscheinlich auf Client-Sicherheitsregeln in der WebSocket-Spezifikation zurückzuführen, um einen Missbrauch von Websocket zu verhindern. (z. B. zum Suchen nach offenen Ports auf einem Zielserver oder zum Generieren vieler Verbindungen für einen Denial-of-Service-Angriff).

Beachten Sie, dass Chrome häufig einen engen Code 1006 meldet, wenn während des HTTP-Upgrades auf Websocket ein Fehler auftritt (dies ist der Schritt, bevor ein Websocket technisch "verbunden" wird). Aus Gründen wie der fehlgeschlagenen Authentifizierung oder Autorisierung oder der Verwendung eines fehlerhaften Protokolls (z. B. das Anfordern eines Subprotokolls, der Server unterstützt jedoch nicht dasselbe Subprotokoll) oder sogar den Versuch, mit einem Serverstandort zu kommunizieren, der kein Websocket ist ( wie der Versuch, eine Verbindung zu ws://images.google.com/ herzustellen)

Wenn Sie einen nahen Code 1006 sehen, haben Sie grundsätzlich einen sehr niedrigen Fehler mit dem Websocket selbst (ähnlich wie "Datei kann nicht geöffnet werden" oder "Socket-Fehler"). Dies ist nicht wirklich für den Benutzer gedacht, da er auf einen niedrigen Pegel hinweist Ausgabe mit Ihrem Code und Implementierung. Beheben Sie Ihre Probleme auf niedriger Stufe, und wenn Sie verbunden sind, können Sie sinnvolle Fehlercodes hinzufügen. Sie können dies in Bezug auf Umfang oder Schweregrad in Ihrem Projekt erreichen. Beispiel: Info- und Warnstufe sind Teil des spezifischen Protokolls Ihres Projekts und verursachen keinen Verbindungsabbruch. Bei schwerwiegenden oder schwerwiegenden Meldungen wird auch das Protokoll Ihres Projekts verwendet, um so viele Details zu übermitteln, wie Sie möchten, und dann die Verbindung mit den begrenzten Fähigkeiten des Websocket-Close-Flows zu schließen.

Beachten Sie, dass die WebSocket-Abschlusscodes sehr genau definiert sind und dass der Satz/die Nachricht für den Grund für den Grund nicht länger als 123 Zeichen sein darf (dies ist eine absichtliche Beschränkung für das Websocket).

Es ist jedoch nicht alles verloren, wenn Sie diese Informationen nur aus Debugging-Gründen wünschen. Die Details der Schließung und der zugrunde liegende Grund werden in der Javascript-Konsole von Chrome häufig mit einer großen Menge Details angegeben.

83
Joakim Erdfelt

Ich habe den Fehler erhalten, als ich Chrome als Client und golang gorilla websocket als Server unter nginx proxy verwendet habe

Und das Senden einer Ping-Nachricht vom Server zum Client alle x Sekunden löste das Problem

1
BIOHAZARD

Es sieht so aus, als wäre dies der Fall, wenn Chrome nicht dem WebSocket-Standard entspricht. Wenn derServer close initiiert und close-Frame an einen Client sendet, betrachtet Chrome dies als Fehler und meldet dies mit JS-Seite Code 1006 und keine Grundmeldung .. In meinen Tests reagiert Chrome niemals auf vom Server eingeleitete nahe Frames (close code 1000), was darauf hindeutet, dass Code 1006 wahrscheinlich bedeutet, dass Chrome einen eigenen internen Fehler meldet.

P.S. Firefox v57.00 behandelt diesen Fall ordnungsgemäß und übermittelt die Server-Grundnachricht erfolgreich an die JS-Seite.

0
user10663464

In meinem und möglicherweise @BIOHAZARD-Fall war es nginx proxy timeout. Standardmäßig ist es 60 sec ohne Aktivität im Socket

Ich habe es in nginx auf 24h geändert und das Problem wurde behoben

proxy_read_timeout 86400s;
proxy_send_timeout 86400s;
0
MixerOID