What does CloseWrite on a *net.TCPConn do, and what does the peer's next Read return?

## Two streams, not one pipe A TCP connection is full duplex: there is a stream from A to B and a separate stream from B to A, and each can end independently. That state — one direction finished, the other still open — is a **half-close**, and it is perfectly legal TCP. Go exposes it on the concrete connection types. `*net.TCPConn` has: ``` func (c *TCPConn) CloseWrite() error func (c *TCPConn) CloseRead() error ``` `CloseWrite` sends a FIN for your sending direction. Everything you already wrote is still delivered; nothing is discarded. Afterwards your writes fail, but your reads keep working normally until the peer closes its own direction. ## What the peer observes The peer drains whatever is still buffered, and then its next `Read` returns `io.EOF` — the same clean end-of-stream it would get from a full `Close`, and distinguishable from an abort. Concretely, a server doing `body, err := io.ReadAll(conn)` blocks forever against a client that keeps its write side open, and returns as soon as that client calls `CloseWrite`. That is the classic use: a protocol where the request length is not known in advance and there is no terminator byte. The client writes the request, half-closes, and reads the response from the still-open reverse stream. ## Why not just Close? `Close` shuts down both directions and releases the descriptor. On a request/response exchange that means you destroy your own read side along with the write side, so the reply you asked for is unreadable — and depending on timing and unread data, the kernel may send an RST rather than a graceful FIN, which the peer sees as a connection reset rather than an orderly end. `CloseWrite` is the narrower tool: end my half, keep yours. You still call `Close` when the exchange is over; `CloseWrite` does not free the file descriptor, so skipping the final `Close` leaks it. ## Getting at the method `net.Conn` is an interface and does **not** declare `CloseWrite`. To reach it, either keep the concrete type from `net.DialTCP`, or type-assert: ``` if tc, ok := c.(*net.TCPConn); ok { _ = tc.CloseWrite() } ``` A better habit in library code is to assert to a capability interface you declare yourself: ``` type closeWriter interface{ CloseWrite() error } ``` because `*net.UnixConn` and `*tls.Conn` implement it too, so the same code path works over a Unix socket or a TLS session. (For TLS this matters more than it looks: the TLS layer must send its own close-notify alert, and its `CloseWrite` does that for you.) `CloseRead` is the mirror and is far rarer — and more dangerous — because data the peer keeps sending after you close your read side has nowhere to go, and the kernel will typically reset the connection. ## Where it interacts with deadlines Half-close and deadlines solve adjacent problems and are easy to confuse. `CloseWrite` gives the peer a **positive signal** that your side is finished, so it can stop waiting. A read deadline is what protects you when no such signal ever arrives — the peer crashed, or a middlebox dropped the flow. A well-behaved wire layer uses both: half-close for the orderly case, deadlines so the disorderly case is bounded rather than a hang. One caution: after `CloseWrite`, the connection is no longer reusable for another request. In a pooled client this means a half-close is a decision to spend the connection, which is why length-prefixed and delimited protocols — the ones that can keep a connection alive for many exchanges — generally do not use it. ## Reading the failure mode If you see a server goroutine parked in `io.ReadAll` or `io.Copy` on a connection that logs say has received the whole request, a missing half-close on the client is a prime suspect: the server is politely waiting for an end-of-stream that the client never sends and, without a read deadline, will wait forever.