Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

[Pavel Rappo]

Thanks Joakim, 

Yes, that's the plan. I would also add 1015.

Thanks,
-Pavel

> On 22 Jun 2016, at 13:50, Joakim Erdfelt <joakim.erdfelt at gmail.com> wrote:
> 
> On Wed, Jun 22, 2016 at 5:39 AM, Pavel Rappo <pavel.rappo at 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