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.
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.
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#...