Fixed SockJS closure with correct close status code

[slinkydeveloper]

As explained here #809 and here #804

[vietj]

we also need to handle the EventBusBridge#checkCallHook method basically wherever the EB bridge closes the socket we need to check which code to use

[slinkydeveloper]

What do you think about 1002? "1002 indicates that an endpoint is terminating the connection due to a protocol error."

[slinkydeveloper]

The close call you are talking about is called after the bridge rejected the socket connection right? In this case maybe is better 1011 "The server is terminating the connection because it encountered an unexpected condition that prevented it from fulfilling the request." or 1013 "The server is terminating the connection due to a temporary condition, e.g. it is overloaded and is casting off some of its clients." (found here: https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent )

[vietj]

@pmlopes any opinion on the code to use ?

[pmlopes]

@slinkydeveloper @vietj regarding the code, i can't find a clear reference that states which code to use, but it seems that 1001 is ok as the eventbus is going away.

Regarding the checkCallHook i think we need to make the new extra method close(int code, String message) a public API so it's up to the user to properly close it as their wishes.

[vietj]

@pmlopes for the new API, the status code has only meaning for Websocket and does not have for other transports...

[vietj]

Need to test the case of invalid message, the client sends an invalid message that force the connection to be closed by the bridge

[slinkydeveloper]

Investigating a bit inside sockjs-client it seems that both status code and reason are handled by client APIs, but it's not clear how they are transported with transports different from Websocket.

[vietj]

for other transport, we just close like we do today.

[vietj]

Can you add the handling for protocol error @slinkydeveloper ?

[slinkydeveloper]

@vietj any tips on how test it?