I think there's 3 possible ways we could set the closure code:-
a) Ignore it and just use 1000 even for errors unless they specifically WebSockets-related - we're using WebSockets as a transport like TCP. Does anyone ever take any notice of TCP-like failure codes apart from 'its broken' (eg when getting EPOLL_ERR, go look up the error that was last found on the FD)?
b) Map the connack codes to a websockets private use range (which I think you're proposing above)
c) Something else that reflects the semantics needed for WebSockets, eg just 1000 =OK and 1001 =BAD, as the connack codes are being carried in the higher-layer (MQTT packets)
In practice, I can imagine implementations choosing to use HTTP headers to 'log in' in, so even some of the CONNACK codes might not be encountered. So I'd go for (b), but as a MAY, simply because not all implementations will be able to set the code (including those being bridged). In practice, this means that clients can't rely on a normal closure code actually being normal closure (because a bridge might not know unless it detects a broken TCP socket session).
For reason texts, I'd propose either:-
a) SHOULD set it to the connack description (if using b)
b) MAY instead of SHOULD
c) Freeform
I'd go for c unless we have a need to distinguish error conditions by text rather than code (which I think is unlikely).
I think there's 3 possible ways we could set the closure code:-
a) Ignore it and just use 1000 even for errors unless they specifically WebSockets-related - we're using WebSockets as a transport like TCP. Does anyone ever take any notice of TCP-like failure codes apart from 'its broken' (eg when getting EPOLL_ERR, go look up the error that was last found on the FD)?
b) Map the connack codes to a websockets private use range (which I think you're proposing above)
c) Something else that reflects the semantics needed for WebSockets, eg just 1000 =OK and 1001 =BAD, as the connack codes are being carried in the higher-layer (MQTT packets)
In practice, I can imagine implementations choosing to use HTTP headers to 'log in' in, so even some of the CONNACK codes might not be encountered. So I'd go for (b), but as a MAY, simply because not all implementations will be able to set the code (including those being bridged). In practice, this means that clients can't rely on a normal closure code actually being normal closure (because a bridge might not know unless it detects a broken TCP socket session).
For reason texts, I'd propose either:-
a) SHOULD set it to the connack description (if using b)
b) MAY instead of SHOULD
c) Freeform
I'd go for c unless we have a need to distinguish error conditions by text rather than code (which I think is unlikely).