graphql-transport-ws rejection specification about graphql-ws HOT 7 CLOSED

Sure, a recommendation sounds good. But please make it 4403: Forbidden instead because that is what the library uses if you return false in the onConnect hook:

from graphql-ws.

Simply closing the websocket is not ideal, since that is a separate protocol layer.

Why not? This is the reason why there is no positive rejection. You have an abundance of user-land close codes (4000-4999) that can be accompanied with any 123 character reason.

Furthermore, you can close the connection at any time (even after acknowledging the connection, or before even considering the connection) and it is very convenient to do so within graphql-ws hooks.

We could specify that the standard way is to close the websocket with some specific error code.

The standard is to close the connection with a close event. GraphQL over WebSocket is a subprotocol under WebSockets, meaning - the conventions of WebSockets are recommended and implied. The spec should be kept as light as possible, it should aim to standardise the GraphQL relevant transport with enough constraints but very small overhead.

from graphql-ws.

Okay, still user-land error codes are always ambiguous. When writing an implementation conforming to a protocol and expecting good interoperability, it is great to have rules and recommendations and as little ambiguity as possible. The protocol already defines a few 4xxx codes to use.

Could we agree on a websocket close code in this case? Would you accept a PR where this recommendation on how to reject a connection_init request is made explicit? Maybe the 4401: Unauthorized message?

from graphql-ws.

🎉 This issue has been resolved in version 5.12.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

from graphql-ws.

My bad, I referenced the wrong issue when merging #456.

from graphql-ws.

Ok, created a PR. There is code out there written in different programming languages which is trying to follow the spec, and not necessarily reverse engineering the .ts source :)

from graphql-ws.

🎉 This issue has been resolved in version 5.12.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

from graphql-ws.