When Gateway terminates a native connection, it sends 1000 as the CLOSE code as part of the CLOSE WebSocket frame. However, when Gateway terminates an emulated connection, it sends the CLOSE command frame that looks like this as per wseb/1.0:
0x01 0x30 0x32 0xFF
In wseb/1.0 protocol, we(Gateway and the clients) do not have the ability to send/receive the CLOSE code as part of CLOSE command frame. Since there is no CLOSE code available in wseb/1.0 CLOSE command frame, all the clients fallback to RFC 6455 mandated 1005 CLOSE code. This causes the behavior between native and emulated modes to be different.
If we have to fix this issue without going to wseb/1.1 in the short-term, then it has to be addressed in ALL the clients. When server terminates an emulated connection, the emulated client should report 1000 as the CLOSE code. However, when an emulated client initiates the closing handshake, it should use 1005 as the CLOSE code.
Copied from original issue: kaazing-private/gateway.client.javascript#12
From @sanjay-saxena on October 22, 2015 18:44
When Gateway terminates a native connection, it sends
1000as the CLOSE code as part of the CLOSE WebSocket frame. However, when Gateway terminates an emulated connection, it sends the CLOSE command frame that looks like this as perwseb/1.0:In
wseb/1.0protocol, we(Gateway and the clients) do not have the ability to send/receive the CLOSE code as part of CLOSE command frame. Since there is no CLOSE code available inwseb/1.0CLOSE command frame, all the clients fallback to RFC 6455 mandated1005CLOSE code. This causes the behavior between native and emulated modes to be different.If we have to fix this issue without going to
wseb/1.1in the short-term, then it has to be addressed in ALL the clients. When server terminates an emulated connection, the emulated client should report1000as the CLOSE code. However, when an emulated client initiates the closing handshake, it should use1005as the CLOSE code.Copied from original issue: kaazing-private/gateway.client.javascript#12