Is there a reason the only 1xxx close code allowed is 1000?

[dead-claudia]

Edit: Formatting and add a couple other codes.

In https://websockets.spec.whatwg.org/#dom-websocket-close, the first step is this:

1. If code is present, but is neither an integer equal to 1000 nor an integer in the range 3000 to 4999, inclusive, throw an "InvalidAccessError" DOMException.

I can understand 1000 being allowed as well as some being disallowed for security (like 1002 and 1005) and/or technical (like 1001 and 1006) reasons. But some of the other 1xxx status codes seem like they'd make sense for a client to return back to the server:

• 1008 is semantically analogous to a 4xx HTTP error. From the RFC (emphasis added):

  1008 indicates that an endpoint is terminating the connection because it has received a message that violates its policy. This is a generic status code that can be returned when there is no other more suitable status code (e.g., 1003 or 1009) or if there is a need to hide specific details about the policy.

  One potential use case here is a client receiving an invalid message from the server that leaves the client in an invalid connection state and the only safe way to proceed is to close the connection. (Essentially just not trusting the server.)

• 1011 is semantically analogous to a 5xx HTTP error. From the RFC (emphasis added):

  1011 indicates that a server is terminating the connection because it encountered an unexpected condition that prevented it from fulfilling the request.

  One potential use case here is a client being left in a fatally erroneous state and seeing it safer to disconnect than to continue.

• 1003 would be useful at the very least for cases where the client can only accept binary frames or can only accept text frames. Even if this isn't explicitly supported as a user status code, it'd be nice to at least be able to maybe declare it in the constructor so it can be handled appropriately.

• 1013 would be useful for signaling client-side timeouts, in case the client is doing active pinging of the server to ensure server availability (relevant for more real-time use cases like multiplayer games).

Of course, I may be mistaken and misinterpreting the RFC here. My current workaround is to specify these in the 3xxx range instead of the standard 1xxx.

[ricea]

I wasn't there when this was decided, but I think the intent is that the server can treat these status codes as "trusted" when the client is a browser. How useful this is in practice I'm not sure.

It would probably be good practice to use the private-use codes 4000 to 4015 as mirrors of the codes 1000 to 1015 for JavaScript client use.

1003 would be useful at the very least for cases where the client can only accept binary frames or can only accept text frames.

Specifying the stream type in the constructor is something we might do for WebSocketStream in future.

[dead-claudia]

It would probably be good practice to use the private-use codes 4000 to 4015 as mirrors of the codes 1000 to 1015 for JavaScript client use.

Good callout - probably should be using 4xxx not 3xxx instead.