WebSocket 1006 sê nie watter skakel gebreek het nie
Lees 'n abnormale WebSocket-sluiting as ontbrekende bewyse van die sluitingshanddruk, en bepaal dan of die proxy-opstelling of 'n gevestigde sessie misluk het.
WebSocket-kode 1006 dui op 'n abnormale sluiting sonder die verwagte Close-raam. Dit is gereserveer: 'n eindpunt mag nie 1006 as die status in 'n WebSocket Close-raam stuur nie. Om dit in 'n API-gebeurtenis te sien, is nie 'n bedienerboodskap wat die proxy as die oorsaak aanwys nie.
As die verbinding nooit oopgemaak het nie
Volg die opstelling in volgorde: verbinding met die proxy, proxy-onderhandeling, bestemming-TLS vir WSS, dan die WebSocket-openingshanddruk. 'n Proxy-uitdaging of tonnelverwerping kan die reeks voor die WebSocket-stadium stop.
As dit oopgemaak het en boodskappe gedra het
Teken die bruikbare duur en wat voor die sluiting gebeur het aan. Vervoeronderbreking, toepassing-afsluiting en 'n tussenganger se beleid kan almal 'n ontvanger sonder 'n skoon sluitingsruil laat.
Bewaar die eindpunt, sessie-identifiseerder, laaste aktiwiteit en of 'n normale Close-raam waargeneem is. Vergelyk die blaaier of biblioteek se netwerkfoute met bestemmingslogboeke waar jy dit beheer. Die gebeurteniskode alleen kan nie die ISP, proxy-operateur of toepassingbediener as die bron identifiseer nie.
'n Normale HTTPS-bladsy wat deur dieselfde proxy werk, toets 'n kort uitruiling, nie die leeftyd van hierdie sessie nie. Hou die blaaier se toestand en toepassingskode stabiel wanneer jy die roete verander; anders is 'n suksesvolle herpoging moeilik om te interpreteer.
Herstel die grens wat deur die bewyse ondersteun word. Proxy-verifikasie, TLS-vertroue en toepassing-herverbinding is afsonderlike take, en om elke tydsbeperking te verhoog, kan nie 1006 een daarvan laat aanwys nie.