facebookincubator / SocketRocket

A conforming Objective-C WebSocket client library.
Other
9.54k stars 2.01k forks source link

Wrong close code (1001) is reported when connection is lost before a close handshake has been performed #605

Open ghost91- opened 5 years ago

ghost91- commented 5 years ago

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):

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).

bboyesc commented 5 years ago

I also encountered it. If there is no operation for a period of time, I will report this error. Have you solved it?

bboyesc commented 5 years ago

I found the cause of my problem. It turned out that the server disconnected the stream.