Currently when Tungstenite receives a 1014 close code, for example, it will convert it to a 1002 before surfacing it to the application, because of:
This seems wrong because 1014 appears to be officially recognized as meaning Bad Gateway:
https://www.iana.org/assignments/websocket/websocket.xhtml#close-code-number
But it also seems wrong in general because it means that the library is not future-proof to assignments of additional codes, as happened with 1014. It seems safer to pass through unexpected codes unchanged so that someone wishing to use a newer version of the protocol is not forced to upgrade Tungstenite on every server that will handle the connection.
Currently when Tungstenite receives a 1014 close code, for example, it will convert it to a 1002 before surfacing it to the application, because of:
tungstenite-rs/src/protocol/frame/coding.rs
Line 256 in 5e15390
This seems wrong because 1014 appears to be officially recognized as meaning Bad Gateway:
https://www.iana.org/assignments/websocket/websocket.xhtml#close-code-number
But it also seems wrong in general because it means that the library is not future-proof to assignments of additional codes, as happened with 1014. It seems safer to pass through unexpected codes unchanged so that someone wishing to use a newer version of the protocol is not forced to upgrade Tungstenite on every server that will handle the connection.