After a WebSocket endpoint has sent its close frame, what may it still do before the connection is finished?

## Closing is a handshake, and it has two halves A WebSocket connection is closed by an exchange, not by a single message. One side sends a close frame; the other, on receiving it, sends one back; each side reads until it has seen the other's; then the underlying transport connection is closed. The half worth understanding is the gap in the middle. Between sending your close frame and receiving the peer's, your connection is **half-closed**: your sending direction is finished and your receiving direction is still fully live. ## What the specification actually requires The distinction between what is required, what is recommended and what is merely permitted matters here, because people routinely quote one as another: - After sending a close frame, an endpoint **MUST NOT** send any further data frames. That direction is over, unconditionally. - An endpoint that receives a close frame and has not already sent one **MUST** send one in response. - It **MAY** delay sending that response until it has finished sending a message already in progress - which is what lets a fragmented message complete instead of being truncated midway. - Once an endpoint has both sent and received a close frame, it considers the connection closed and closes the underlying transport connection. The server closes that transport; the client **SHOULD** wait for the server to do so rather than closing first. That asymmetry at the end is the part implementations get wrong by accident: both sides racing to tear down the transport is how a clean close turns into an abnormal one in the records. ## What a premature teardown loses An endpoint that sends its close frame and immediately stops reading - or closes the transport on the spot - discards everything the peer had already put on the wire. Concretely, in a crane cabin console shutting down at end of shift: - The final acknowledgements for commands the console issued seconds earlier are thrown away, so the operator's last actions look unconfirmed when they actually succeeded. - The peer's own close frame is never seen, so the ending is recorded as abnormal on at least one side even though both behaved correctly. - A message the peer had begun sending is cut off rather than completed, because the sender is allowed to finish it and the receiver is no longer there to accept it. None of that is a protocol error. It is the ordinary consequence of treating a handshake as a single message. ## The shape of a correct shutdown 1. Stop accepting new outbound messages from the application and send the close frame. 2. Keep the reader running. Deliver whatever data messages still arrive - they are as valid as any that arrived a second earlier. 3. Stop when the peer's close frame arrives, or when a bounded wait expires, so a peer that never answers cannot hold the connection open forever. 4. Let the server close the transport; the client waits for that rather than racing it. ## The wait has to be bounded Step 3 needs saying out loud, because it is where a careful implementation goes wrong in the opposite direction. Having learned not to tear the reader down, people then wait for the peer's close frame indefinitely - and a peer that has crashed, been suspended, or sits behind something that has silently stopped forwarding will never send one. The connection then sits half-closed forever, holding a file descriptor, a buffer and whatever per-connection state the node keeps, which at scale is exactly the leak a deploy is trying to avoid. So the drain is a bounded one: - Give the peer a deadline measured in seconds, not minutes - it only has to answer a frame it has already been sent. - When the deadline expires, abandon the exchange and close the transport yourself. The ending will be recorded as abnormal, which is honest: it was. - Distinguish the two outcomes in whatever you record. A drain that completed and a drain that timed out look identical from the outside and mean very different things about the peer. ## Why it exists at all Half-close is what makes an orderly shutdown possible on a connection where both ends write independently. Without it, either side deciding to finish would destroy the other side's in-flight work as collateral. With it, the deciding side stops talking, both sides drain what is already on the wire, and the connection ends with both ends agreeing that it ended - which is precisely the difference an operator sees between a clean shutdown and a mystery in the records.