Code 4205 vs CloseCode.Forbidden?

[theogravity]

I've seen 4205 defined as Client Restart. Can we get an actual CloseCode definition in for it? Is there a difference in how the server handles the socket in the "graceful restart" code vs the forbidden code used in "client auth usage with token expiration, validation and refresh"?

I saw in another thread for codes:

https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent/code

That 4205 would fall in the private use section.

[enisdenjo]

Guess you're referencing the "Client usage with graceful restart" recipe. The code is freely chosen to be outside of the fatal codes list so that the client may restart after the socket closes. No definition for the "Client Restart" code in graphql-ws because it's not compulsory, the implementor may choose any close code he wants for restarting purposes.

It's called "Client Restart" because the client closes the connection to restart. The idea is, for example, when your connectionParams change you want to reconnect to the server passing along the new parameters - hence, the client needs a restart. Check out PostGraphile's PostGraphiQL for a concrete example.

All custom close codes in graphql-ws fall in the private use section. 0–999 are not used; 1000-2999 are internal codes with predefined meaning; no close code is registered with IANA so no 3000–3999 range; what we're left with is the 4000–4999 range for private use.

When choosing the close codes, I tend to loosely map over the HTTP status codes. For example:

• 4500: Internal server error -> 500: Internal Server Error
• 4400: Bad request -> 400: Internal Server Error
• 4403: Forbidden -> 403: Forbidden
• 4205: Client Restart -> 205: Reset Content
• etc.

Is there a difference in how the server handles the socket in the "graceful restart" code vs the forbidden code used in "client auth usage with token expiration, validation and refresh"?

No, both are considered retryable by the client. They merely transfer meaning helping the implementor understand or act accordingly.