1001 indicates that an endpoint is "going away", such as a server
going down or a browser having navigated away from a page.
RFC 6455 actually defines a close code which can be used in this situation—1006:
1006 is a reserved value and MUST NOT be set as a status code in a
Close control frame by an endpoint. It is designated for use in
applications expecting a status code to indicate that the
connection was closed abnormally, e.g., without sending or
receiving a Close control frame.
If I am informed correctly, 1006 is the close code used by major browsers like Google Chrome in the described situation.
I am not completely sure on the specifics, but it might also be valid to simply regard this as a failure. This is what some other libraries do (e.g. okhttp, although they used the close code 1006 for this at some point in time: https://github.com/square/okhttp/pull/2875).
Currently when the connection is lost before a close handshake has been performed, a close code of 1001 is reported: https://github.com/facebook/SocketRocket/blob/0a023409b138039d1ab5ac5431fe61c5f334e86b/SocketRocket/SRWebSocket.m#L1480 According to RFC 6455, this is wrong because 1001 is a regular close code (see in particular 7.4.1. Defined Status Codes):
RFC 6455 actually defines a close code which can be used in this situation—1006:
If I am informed correctly, 1006 is the close code used by major browsers like Google Chrome in the described situation.
I am not completely sure on the specifics, but it might also be valid to simply regard this as a failure. This is what some other libraries do (e.g. okhttp, although they used the close code 1006 for this at some point in time: https://github.com/square/okhttp/pull/2875).