The graphql websocket protocol uses messages with the text opcode and payload {"type": "ping"}/{"type": "pong"} instead of using the ping and pong opcodes.
At present, graphql-ws-client interprets a text message with payload {"type": "ping"} but responds with a pong message. This can lead to servers dropping the connection, due to receiving a message that doesn't conform with the graphql-transport-ws protocol (see: https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md#ping).
Message::graphql_pong() is already used in ClientBuilder::build() to respond to any ping messages received during connection initialization, but it isn't used for pings received after a subscription has been established.
I discovered this when updating our codebase from graphql-ws-client 0.6.0 to graphql-ws-client 0.10.1, and noticed that the server would respond with a close frame after our client responded to a server-sent ping frame.
obmarg
commented
4 weeks ago
The graphql websocket protocol uses messages with the text opcode and payload
{"type": "ping"}/{"type": "pong"}instead of using the ping and pong opcodes.At present,
graphql-ws-clientinterprets a text message with payload{"type": "ping"}but responds with a pong message. This can lead to servers dropping the connection, due to receiving a message that doesn't conform with thegraphql-transport-wsprotocol (see: https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md#ping).Message::graphql_pong()is already used inClientBuilder::build()to respond to any ping messages received during connection initialization, but it isn't used for pings received after a subscription has been established.I discovered this when updating our codebase from
graphql-ws-client 0.6.0tographql-ws-client 0.10.1, and noticed that the server would respond with a close frame after our client responded to a server-sent ping frame.