Skip to content
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

Server responding with html error message causes an exponential number of retries #38

Open
moritz157 opened this issue Oct 18, 2024 · 0 comments · May be fixed by #39
Open

Server responding with html error message causes an exponential number of retries #38

moritz157 opened this issue Oct 18, 2024 · 0 comments · May be fixed by #39

Comments

@moritz157
Copy link

I have my server running behind Apache as a reverse proxy. If the server is running everything is working fine. If I then stop the server the SSE connection dies and after 5 seconds it tries to reconnect. However if the server is still down Apache responds with a regular html error message. The SSEClient then, line by line, tries to parse the response to single events. Of course this fails for every single line. The problem is that if the parser cannot parse a line it calls _retryConnection while completely ignoring if a previous line already triggered a reconnect. Therefore a single response consisting of for example 10 lines triggers 10 connection retries simultaneously. If the server remains offline, each of those retries then trigger another 10 retries since Apache is still responding with an error. One minute of server downtime therefore results in 10^12 = 1 trillion requests at once (retry interval 5 seconds).

I accidentally kinda DOS'ed myself a number of times before I discovered the problem 😅
I think I am not the only one running my server behind a reverse proxy that responds like this if the server is down and I think this should be prevented.

The simplest solution to this would be to just cancel the response line stream subscription if an error occurs while parsing and therefore only allow one retry attempt. One giant downside of this approach though is that this only logs the first line of the response which isn't really helpful for debugging. So we should think about catching non-event-stream responses early and logging them in full before it could be split up line-by-line.

@moritz157 moritz157 linked a pull request Oct 18, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant