Live data from Hacker News

We found a bug in the hyper HTTP library

blog.cloudflare.com

21–30 of 97 posts

Re: We found a bug in the hyper HTTP library

#21
post #19
post #12

> 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…

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.

Re: We found a bug in the hyper HTTP library

#22
post #19

Earlier quoted context omitted.

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)

Post reply on HN