Proper rate limit error codes in websockets #312

New issue

Open

opened 2025-11-21 08:12:50 +00:00 by Egge21M · 0 comments

Egge21M commented

2025-11-21 08:12:50 +00:00

(Migrated from github.com)

This is an issue, because clients would usually want to try some re-connection logic on network errors, but on rate limit errors this is exactly what not to do.

I think we should extend the websocket nut: If a mint wants to decline an incoming websocket connection it SHOULD NOT decline the upgrade request. Instead a mint SHOULD always open the connection, then send an error frame through the opened connection and close immediately after.

Problem: If a mint declines a websocket protocol upgrade request (for example because the client is already rate limited - HTTP 429), JavaScript implementations will not hand that HTTP error back to the client. Instead JS will throw an error just like it would for general networking issues. There is no way to differentiate between the two. This is an issue, because clients would usually want to try some re-connection logic on network errors, but on rate limit errors this is exactly what not to do. I think we should extend the websocket nut: If a mint wants to decline an incoming websocket connection it SHOULD NOT decline the upgrade request. Instead a mint SHOULD always open the connection, then send an error frame through the opened connection and close immediately after.