1005 status code is incorrectly treated as "abnormal" shutdown

[lpinca]

If the close frame contains no status code (payload length == 0), the close code is 1005. In this case sockette should not reconnect.

Ref: https://tools.ietf.org/html/rfc6455#section-7.1.5

[lukeed]

When do you encounter a 1005 code in a normal setting? In my experience, a 1005 is always unexpected, meaning a closure happened before something had time to write a proper code & reason.

[lpinca]

A simple ws.close() from a server client, unless you specify a close code ofc.

[lukeed]

Yeah, I suppose this is the result of my habit(s). I always send ws.close(OK).

The 1005 code is basically the 204 of WebSockets. Technically okay, but not all that informative/useful.

I'll look into accepting 1005 within onclose & see how it fares in my apps, but sending 1000 intentionally will likely stay. Thanks~!

[lpinca]

To clarify: if the server sends an empty close frame (0x88 0x00) the client closes with 1005 and that isn't an abnormal closure.

sending 1000 intentionally will likely stay.

It's your lib so you can obviously do whatever you want but it is inconsistent with what browsers do. If you don't specify a close code, the close frame should be empty. You prevent the user from sending an empty close frame by forcing a 1000 close code and increase the bandwidth usage by 2 bytes per frame 😄 .

[lukeed]

Yea, for sure! I've always preferred to be explicit with my codes & am not closing connections on a high frequency, so the extra 2 bytes hasn't been an issue 😆.

I'll look at this tonight. Forcing this practice on others probably isn't the right approach... And, unfortunately, changing this probably requires a really sudden 2.0 release lol

Thanks for the feedback~!

[lukeed]

Hey @lpinca, do you mind taking a quick peek and verifying the change for me? Dropped it into my apps and it's still working as expected~

[lpinca]

It looks good. If I'm not wrong you can also remove the fn variable declaration which is no longer used.

[lukeed]

Ah, right! What I get with hurried coding...

I'll fix that, but what do you think about the server? Does this constitute a major change, or is it just a minor after all since the interface API hasn't changed

[lpinca]

The reconnection change is a bug fix. The close() change is arguably a breaking change but imho it is a bug fix as per comment above (if no close code is specified, the close frame should be empty).

[lukeed]

Released in 1.1.0 -- a minor felt more accurate. Thanks again!