-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better spec for how close() / cancel() and the closing promise should act #15
Comments
@ricea is the spec owner. From my DevRel point of view, I agree with you that 2. looks like the way that most developers would expect. |
Yes, this is mildly broken in Chrome too. If the WebSocket is blocked due to backpressure then we'll never read the Close frame. Forcing the user to read from the ReadableStream is effectively what we do, but it goes against the principle of the Enqueuing unread messages when For point 3., are you referring to the
section from RFC6455? Chrome uses a timeout of 2 seconds before closing the connection itself (many servers seem to get this wrong). If we make it configurable I worry that everyone will just set it to zero, defeating the purpose of avoiding the client getting stuck in TIME_WAIT state. |
Yes, from what I can see enqueuing unread messages is the best compromise. This is exactly what I wrote in the PR I contributed at Deno to fix this behaviour, and it fixed my use case nicely. I see the worry about everyone setting it to ZERO. Two seconds seems like a nice time. 5 seconds is the maximum time for most timeouts recommended in the RFC. Can we get away with setting something like This would solve the worry about the server just sending unlimited data while generally working well with RFC compliant servers. |
@ricea Just pinging here, since we're using this in production with Deno's version of WebSocketStream, highly interested in seeing this resolved. |
Sorry. I haven't had time to work on this. If you happen to have time to draft a PR to specify the behaviour, that would be a big help. |
How is
close()
expected to behave if the user stopped reading the ReadableStream but there are a few messages in the queue up for grabs?If you try to implement this spec with a simple ReadableStream you could have some unread messages that the stream didn't pull from the underlying because the user hasn't requested them via
read()
, the stream won't actually get to reading the closing handshake - because the end user still hans't pulled the latest message available in the ReadableStream.For example, the current Deno implementation (which is rightfully hidden behind an
--unstable
flag) is broken because if you have more than 1 incoming message in the queue, and you're not intending to read it before or after callingclose()
, theclosing
promise will essentially remain unresolved. Here is an example of this behavior:denoland/deno#15616
I think the spec needs to be clearer about the mechanics of how to do this, to prevent parties that implement this functionality from running into the same issue and getting too divergent on how they solve this problem.
For example:
WebSocketStreamOptions
?I think this part is trickier than it seems and it can benefit from a higher resolution description on the spec itself so that everyone implements it in a way that would behave the same. Right now it leaves too much room to the imagination.
@ricea @tomayac
The text was updated successfully, but these errors were encountered: