[1] WebSocket の状態符号は、 WebSocket接続を閉じる (閉じられた) 理由を示すものです。
Close フレームの状態符号[3] Closeフレームの応用データの最初の2バイトは、
(あれば) 状態符号を表します。
Closeフレームを参照。[30] WebSocket接続閉じ符号は、
応用が最初に受信した Closeフレームに含まれていた状態符号です。
当該フレームが状態符号を含まない時は、 1005 です。
そのようなフレームが無いまま The WebSocket Connection is Closed
となった場合は、 1006 です。
1005 と 1006 は、
Closeフレームで使ってはなりません。 >>12
[31] サーバーとクライアントはそれぞれ状態符号を送ったり送らなかったりしますが、 両者の認識するWebSocket接続閉じ符号は同じかもしれませんし、違うかもしれません。
CloseEvent インターフェイス code 属性[80] CloseEvent インターフェイスの
code 属性は、WebSocket接続閉じ符号を表します。
[81] この属性は、その属性値として設定された値を返さなければなりません >>77。データ型は unsigned short で、初期値は
0 です >>77。
[42] 次の状態符号が定義されています。1000 は、目的を達し正常に閉じられることを表します >>12。1001 は、サーバーのダウンやWebブラウザーが他ページに
navigate したなど通信の当事者が“いなく”なったことを表します >>12。1002 は、プロトコルエラーにより接続を閉じることを表します
>>12。1003 は、受け付けられないデータの種類のため接続を閉じる
(例えばテキストしか理解できないのにバイナリーを受信した) ことを表します >>12。1007 は、データが種類に合っていない
(例えばテキストのはずなのに UTF-8 データでない) ため接続を閉じることを表します
>>12。1008 は、方針に反するメッセージを受信したため接続を閉じることを表します。
他により適切な状態符号がない時や、隠す必要がある時に使うことができます。 >>121009 は、メッセージが大きすぎるため接続を閉じることを表します
>>12。1010 は、handshake 時にサーバーが期待していた拡張を返さなかったためにクライアントが接続を閉じることを表します。
必要な拡張を Closeフレームの理由部分に記述するべきです。 >>121011 は、予期せぬ状況で要求を満足できず、接続を閉じることを表します >>12, >>54。1012 は、サービスが再起動されたことを表します。
クライアントは再接続して構いません。その場合 5s-30s から無作為に選んだ分遅延して再接続するべきです。 >>571013 は、サービスが過負荷であることを表します。
クライアントは、(あれば) 異なる IPアドレスに接続するか、
利用者の指示があれば同じ IPアドレスに再接続することとするべきです。 >>57
[44] 1015 は、TLS handshake に失敗して接続が閉じられたことを示します。
Closeフレームで使ってはなりません。 >>12
また利用者エージェントは使用しません >>62。
[46] 1000-2999 は、公開された仕様書で規定されるプロトコルや拡張により、
永続的なものとして利用します >>12。
[47] 3000-3999 は、
ライブラリー、フレームワーク、応用で使うために予約されています。
IANA登録簿に登録できます。 >>12
[48] 4000-4999 は、
私用に予約されています。IANA登録簿に登録できません。
応用間の事前の合意で使うことができます。 >>12
[65] 使ってはならない状態符号や予約されている状態符号は、 使ってはならないだけで、使われない保証は無いようです。
[4] WebSocket インターフェイスの
close メソッドでは、 1000
と 3000-4999 しか認められていません。
それ以外は例外が投げられます。
[10] 現実には、WebSocket状態符号はあまり積極的に利用されていないようにみえます。
[11] 接続失敗の場合について、WebSocket状態符号にはあまり有用な情報は現れません。 特にクライアントについては、セキュリティーのため、 敢えて失敗の詳細な理由がスクリプトに明かされないことになっています。
[13] 従って実質的には正常終了の場合にしか使いようがありませんが、 通常のデータとして送信せずに接続を閉じつつ情報を送らなければならない場面はほとんどありません。 より詳細な情報 (例えば受信したメッセージが不正だった時に、 そのエラーの詳細情報) を含めたいとすると、一応 WebSocket接続閉じ理由もあるとはいえ、 通常のデータで送ってから接続を閉じる方が考えることは少なくて済みます。
[7] 状態符号や理由は、 Ian Hickson 時代の WebSocket プロトコルには存在しませんでしたが、その後 IETF hybi により追加されました。
[8] [hybi] WebSocket Subprotocol Close Code: Bad Gateway () <https://www.ietf.org/mail-archive/web/hybi/current/msg10748.html>
1011 Internal Error [IESG_HYBI] [RFC6455][RFC Errata 3227]
1012 Service Restart [Alexey_Melnikov] [http://www.ietf.org/mail-archive/web/hybi/current/msg09670.html]
1013 Try Again Later [Alexey_Melnikov] [http://www.ietf.org/mail-archive/web/hybi/current/msg09670.html]
1014 The server was acting as a gateway or proxy and received an invalid response from the upstream server. This is similar to 502 HTTP Status Code. [Alexey_Melnikov] [https://www.ietf.org/mail-archive/web/hybi/current/msg10748.html]
1015 TLS handshake [IESG_HYBI] [RFC6455]