Why does reading from the net.Conn returned by Hijack lose bytes the client already sent?

## Where the missing bytes went Nothing in `net/http` reads a request byte at a time. Each connection is served through a `*bufio.Reader`, and every fill of that buffer takes whatever the socket currently holds — up to the buffer size — not just the part that belongs to the request head. If the peer wrote the upgrade request and the first bytes of the new protocol in the same burst, the kernel may hand both to that one read. The request parser consumes the head and stops; the rest stays in the bufio buffer. So at the moment `Hijack` returns, the connection's data lives in two places: - whatever the buffered reader is still holding, already drained from the kernel; - whatever the client sends from now on, still in the socket. That is exactly why the signature is `Hijack() (net.Conn, *bufio.ReadWriter, error)` and not just `(net.Conn, error)`. The `*bufio.ReadWriter` is not a convenience wrapper — it is the only handle on the first group. ## The bug ```go conn, brw, err := hj.Hijack() // ... write the handshake ... n, err := conn.Read(buf) // WRONG ``` This reads the socket directly and therefore begins with whatever the client sends *next*. Anything already buffered is skipped, forever. Depending on the protocol you are speaking, the result is a corrupt first frame, a desynchronised parser, or a session that simply stalls waiting for a message it already received. The correct form reads through the returned reader, which drains its buffer first and then falls through to the socket: ```go n, err := brw.Read(buf) // correct ``` Once you are reading through `brw`, keep doing so for the whole life of the connection; do not alternate between `brw` and `conn` on the read side. ## Why it hides in testing Hand-written test clients tend to write the request, read the 101, and only then write protocol data — three separate syscalls with the server's reply in between, which guarantees the server's buffer is empty at hijack time. Real clients pipeline: they write the request and their first message together to save a round trip, and TLS makes it worse by delivering whole records at once. So this defect ships green and fails against the first efficient client, usually as "the session works but the very first message is lost". ## Confirming it `brw.Reader.Buffered()` returns the number of bytes currently held in the reader. Logging it immediately after `Hijack` tells you unambiguously whether the connection arrived with data in hand. Note the qualification: `*bufio.ReadWriter` embeds both a `*bufio.Reader` and a `*bufio.Writer`, and **both** types have `Buffered`, `Reset` and `Size` methods, so the selector `brw.Buffered()` is ambiguous at the same embedding depth and does not compile. You must say `brw.Reader.Buffered()` or `brw.Writer.Buffered()`. Method names that appear on only one half — `Flush`, `WriteString`, `Read`, `ReadString`, `Peek` — promote normally and can be called on `brw` directly. ## The write side is different On the write side there is no equivalent trap: the server has nothing pending for you, and writing to `conn` directly is legitimate. The only rule is not to interleave `conn` writes with buffered `brw` writes without flushing in between, since the buffered bytes would then arrive after the direct ones. ## The rule of thumb Treat the `net.Conn` from `Hijack` as the thing you close and configure, and the `*bufio.ReadWriter` as the thing you read. If you truly want to hand a plain `net.Conn` to some other library, drain the buffered reader first — check `Buffered()` and copy what it holds — rather than assuming it is empty because it usually is.