Thanks Joakim, Yes, that's the plan. I would also add 1015.
Thanks, -Pavel > On 22 Jun 2016, at 13:50, Joakim Erdfelt <joakim.erdf...@gmail.com> wrote: > > On Wed, Jun 22, 2016 at 5:39 AM, Pavel Rappo <pavel.ra...@oracle.com> wrote: > *. Please notice the difference between range of status codes accepted in > `sendClose` and passed to `onClose`. > So basically WebSocket will allow to receive status codes up to 65535 > (inclusive), but will not allow to send them if they are greater than 4999. > > The reason I'm proposing this is that (in contrast to [0, 999]) RFC 6455 does > not actually contain explicit prohibition for using codes from the range > [5000, 65535]: > > https://tools.ietf.org/html/rfc6455#section-7.4.2 > > Some might say it's an undefined behaviour. For example, Autobahn|Testsuite > sees > it as such: > > http://autobahn.ws/testsuite/reports_20131013/clients/ie11_preview_case_7_13_1.html > http://autobahn.ws/testsuite/reports_20131013/clients/ie11_preview_case_7_13_2.html > > I think in this case it would be fine to rely on famous "Robustness principle" > an allow such an asymmetry: > > ...be conservative in what you do, be liberal in what you accept from > others > > And since RFC 6455 says WebSocket SHOULD echo back the received close code: > > If an endpoint receives a Close frame and did not previously send a > Close frame, the endpoint MUST send a Close frame in response. (When > sending a Close frame in response, the endpoint typically echos the > status code it received.) It SHOULD do so as soon as practical. > > WebSocket should normally send back the same code it received. Even if it's > outside the "normal range": [1000, 4999] > > What would you say? Thanks. > > The only exceptions being codes 1005 and 1006. > > If you receive those from a remote endpoint, you should close immediately and > reply with code 1002 (protocol error) > > - Joakim
