mitm: flush response writes per-chunk so streaming responses are delivered live

[devniel]

Problem

The forward path in internal/mitm/forward.go writes the upstream response body with:

_, _ = io.Copy(w, io.LimitReader(resp.Body, brokercore.MaxResponseBytes))

That leaves chunk delivery to the http.ResponseWriter's default coalescing. For non-streaming responses (single JSON body with Content-Length) that's fine — one Write, one delivery. For streaming protocols layered on top of HTTP, the client needs each upstream chunk to arrive promptly. When it doesn't, downstream parsers stall or abort mid-response.

The concrete failure that prompted this PR: git clone over HTTPS through the proxy. After authentication (Basic / Bearer / api-key) is correctly injected, the actual pack transfer fails with:

error: 6650 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

git's sideband pack-protocol parser is built on top of HTTP and uses its own framing within the response body. Without per-chunk flushing, byte boundaries from upstream collapse into a buffered blob, the parser hits a stall at the wrong point, and the connection is closed before the final packet arrives.

Same class of bug bites:

• SSE event streams (events buffered until upstream closes the body)
• Long-running gRPC-over-HTTP/2 streams
• Anything else that relies on upstream byte boundaries being preserved end-to-end

Change

Wrap the ResponseWriter in a flushingWriter that calls Flush() after every successful Write, so upstream chunk boundaries reach the client unbuffered:

if f, ok := w.(http.Flusher); ok {
    _, _ = io.Copy(&flushingWriter{w: w, f: f}, io.LimitReader(resp.Body, brokercore.MaxResponseBytes))
} else {
    _, _ = io.Copy(w, io.LimitReader(resp.Body, brokercore.MaxResponseBytes))
}

flushingWriter is dead-simple (Write → Flush) and doesn't change semantics for non-streaming responses — io.Copy already does a single Write in that case, so the extra Flush is a no-op.

Regression test

TestMITMForwardStreamsChunksPromptly (new) wires an upstream that writes N chunks separated by 80ms delays, flushing each, and asserts the arrivals at the client are spread across time. On the prior io.Copy-only path, all chunks land in a single read after the upstream's final sleep — the test fails with:

chunks arrived in 5.958µs; expected ≥ 120ms
(proxy is buffering instead of flushing per-chunk)

With the fix the spread is preserved and the test passes.

Verification

• New regression test passes; baseline (pre-fix) fails clearly with the diagnostic above
• Full internal/mitm/ test suite green (go test ./internal/mitm/... -count=1)
• Verified locally: git clone of a real GitHub repo through the proxy completes successfully (was failing with early EOF before)

---

Opening as a draft to invite review on the approach. Two alternatives I considered and would happily switch to if the maintainers prefer:

1. httputil.ReverseProxy — swap the hand-rolled copy entirely. Larger blast radius, but FlushInterval=-1 is the idiomatic Go answer for proxying streaming responses. I held off because the existing forward code is doing a few non-trivial things (LimitReader cap, custom header strip, request-log emission) that would need to be wired up via ModifyResponse/ErrorHandler/Transport callbacks.
2. http.NewResponseController(w).Flush() periodically on a timer, similar to ReverseProxy's FlushInterval. Slightly more complex, marginally more efficient on tiny chunks. The per-Write Flush in this PR is plenty fast in practice and easier to reason about.

[saifsmailbox98]

superseded by #229