-
Notifications
You must be signed in to change notification settings - Fork 76
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
Plug.Conn is not closed when user closes the browser's tab (SSE) #344
Comments
Sorry for the late response! I think this may rhyme with #202 and #305. I've pushed up a branch that disables exit trapping on HTTP/1 connections (so they'll close as soon as the underlying socket gets closed remotely). It's up on a test branch at:
Note that the above is just an experiment branch; a couple of telemetry flows may not work 100% as expected. I just want to get a sense of whether this is the correct approach. Specifically for the folks involved in this / adjacent PRs:
In all cases, I'd greatly appreciate objective feedback so I can assess which of the approaches to refine & land. Thanks all! |
Hi @mtrudel, thanks! I will test those changes on Thursday |
I've tightened up the semantics on this and pushed up a proper PR at #346. I'd love feedback to see if this fixes your issues @mickel8, @MrYawe, @hubertlepicki |
@mtrudel sorry for the late response. I am testing branch |
I tried both with trapping exits and without. In any case, I am not notified that the process that handles incoming request was closed. |
@mtrudel I've created minimal reproducible project: https://github.com/mickel8/bandit_sse When you run it with When you uncomment Plug.Cowboy in |
Hi @mtrudel! I have debugged this more and:
It looks like that to solve the problem we should check against the return value of ThousandIsland.Socket.send and either propagate {:error, :closed} to the Plug's user or raise as in the case of ThousandIsland.Socket.recv |
Let me know what you think. Maybe I could try to submit a PR |
What to do with return values from those calls is something I went back and forth on a few times in 1.4. TBH, it's tough to surface this sort of thing via the Plug API; it's a simple abstraction that's easy to understand, but it's a bit at odds with so much of the realtime nature of OTP. Leave it with me; I'll get a branch up shortly for test. |
Perfect! Thanks 🙂 Just out of curiosity. Isn't returning {:error, :closed} tuple desired here? Is it against OTP design prinicples? Plug even have an example for |
For sure messages are no longer sent but now I am getting the following error
If you want to, you can run this example: https://github.com/mickel8/bandit_sse |
Sorry, I misread the log. It's from my code. Yeap, looks that everything works except that the error tuple returned from |
Yeah, the main thrust of this work is to better surface errors on sending, so it's expected that you'll now be seeing those errors (previously we just silently ate them). I'll update the text of that error; should only be sending the underlying exception's message as the reason. Thanks for testing! |
Hi,
I have implemented SSE (Server-Sent-Events) using Plug and Bandit, and they work really cool until a user closes browser's tab. For some reason, my Plug.Conn isn't notified/invalidated and I can still send data (although it doesn't appear in Wireshark). The code looks more or less like this
When I switched to the cowboy, everything works as expected, i.e. once the tab is closed, a process handling a connection on the server side is also closed.
The text was updated successfully, but these errors were encountered: