> The failure was caused by a timing-dependent race condition in hyper’s HTTP/1 connection handling. When the reader was slower and the socket buffer filled, poll_flush returned Poll::Pending, but the dispatch loop discarded that result. Hyper then treated the response as complete and shut down the socket while data remained buffered internally, causing the client to receive an EOF before the full body arrived.
https://github.com/hyperium/hyper/issues/4022
Saved you 3000 words
Reminds me of another “slow client”-related bug in gunicorn: https://github.com/benoitc/gunicorn/issues/3334
That's not even a bug. That's how TCP works. If you keep sending data to a socket the other side has closed, you get RST.
In case of plain HTTP over TCP, there is even a hint in the spec about why and how a server might want to avoid fully closing prematurely.
https://datatracker.ietf.org/doc/html/rfc9112#section-9.6 (this was already in https://datatracker.ietf.org/doc/html/rfc7230#section-6.6)
This is relevant if the client sends multiple requests but the server decides to close the connection after one of them. The server should discard the additional requests until the client signals no more requests are coming.
what is RST?
connection reset - TCP says "this connection is too messed up, abort, abort!"
The relevant condition here is where one side closed its socket but the other side didn't and keeps sending data to the closed socket. That's obviously an improper way to end a connection. A graceful shutdown does not send RST and ensures all data is received on both sides.
Connection "reset": https://en.wikipedia.org/wiki/Transmission_Control_Protocol#...
Hey, you have to justify three engineers full time's worth of salary.