Raphael Cohen (Inactive) added a comment - 10/Oct/13 12:47 PM 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).