mirror of
https://github.com/storytold/deckcraft.git
synced 2026-10-26 19:46:58 -06:00
Hamza
900f62f5a3
A client that sent another line while its previous one was being rejected never saw the reason. `serve` writes the error and drops the socket; the client's second write lands on a socket the server has already closed, the kernel answers it with RST, and an RST discards what was queued for the client -- including the reply. The client reads a connection reset instead of being told why. The comment there, "a peer that can't read the reason loses nothing", holds for a peer that stopped reading. A peer that is reading loses the reason, and it is the one that gets reset. `close_politely` shuts the write side down so the FIN follows the reply, then reads and discards for up to the write timeout and at most 64 KiB, so the peer's pipelined line is absorbed instead of answered with RST. Both paths that reject and close use it: a line that is not a request, and a line over the length limit. A peer that keeps talking is still dropped at the deadline. This is also why `a_line_that_is_not_a_request_closes_the_connection` was red about four times in five: it writes a second line after the junk one. Run alone twelve times, it failed 10 on `main`, 0 with the second line removed, and 0 with this change and the second line kept.