Hi, On Thu, Jun 2, 2016 at 10:40 PM, Pavel Rappo <pavel.ra...@oracle.com> wrote: > 1. Are there any cases where the app needs to know that Close message was in > fact > empty?
Not that I know. > 2. Does the app behaviour (especially, parsing the reason phrase/description) > depend on the status code? Not much really. My experience is that it is only logged. Even when a server closes a connection for idle timeout or shutdown, there is not much that the client can do. For a client receiving a 1001 or a network exception, it can only show to the client application something like "connection lost" and retry periodically to contact the server again. > 3. If the app initiates the Closing handshake, what Close message does it > send? Until a little time ago, browsers were forbidding to send a close with a code != 1000. Now looks like they have relaxed this restriction. Not sure how many applications make use of different codes, but I don't think many. > 4. Which codes does the app distinguish? Here is the gist of the whole thing. WebSocket is a very low-level protocol. Applications don't use "WebSocket", they use a protocol on top of WebSocket. Take Bayeux (https://docs.cometd.org/current/reference/#_bayeux), for example: it has its own "connect" and "disconnect" semantic *on top* of WebSocket. Take WAMP (http://wamp-proto.org/spec/), it has a HELLO and GOODBYE messages *on top* of WebSocket. GOODBYE even has close codes that duplicates those defined in WebSocket (e.g. 1001). And so on. So at the end, applications don't really use the WebSocket close codes because WebSocket is only used as a transport protocol for some other protocol (unless very simple cases). I'd keep it simple and clear, and always offering a close code in the API (and thus get rid of the Optional). Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
