Add defensive gzip decompression for backend responses

[clintonb]

Streamable backend responses occasionally reach mcp-go's JSON decoder still gzip-compressed, failing with invalid character '\x1f' looking for beginning of value. One known trigger is an explicit Accept-Encoding on the outgoing request disabling Go's transparent decompression (fixed at the source in #62), but compressed bytes reaching the decoder is worth guarding against regardless — a double-encoding edge or any future header regression produces the same hard-to-diagnose failure.

A gzipGuardTransport RoundTripper now wraps the streamable backend HTTP client. If a response still carries Content-Encoding: gzip, or an application/json body starts with the gzip magic bytes, the body is wrapped in a gzip reader — looping to handle double-encoded bodies, capped at depth 5. The sniff uses a non-consuming bufio.Reader.Peek, so plain JSON, empty bodies, and false alarms pass through byte-identical, and text/event-stream responses are never touched. When the guard fires it logs a WARN with the backend host, request method, response status, the outgoing Accept-Encoding, content headers, and which trigger fired — in production this telemetry is what identified the root cause fixed in #62.

Unit tests cover plain passthrough, header-path and sniffed decompression, double-gzip, SSE passthrough, empty bodies, close propagation to the underlying body, and a gzip header with a non-gzip body.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces a gzipGuardTransport (an http.RoundTripper) to transparently handle and decompress gzip-encoded response bodies (including nested/double-encoded bodies) before they reach the JSON decoder in the streamable HTTP client. It also includes comprehensive unit tests covering various response scenarios. The review feedback suggests optimizing memory allocation and reducing GC pressure by using bufio.NewReaderSize with a minimal buffer size instead of the default 4KB bufio.NewReader when peeking for gzip magic bytes.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

By default, bufio.NewReader allocates a 4KB buffer. Since this transport wraps every streamable HTTP client response, allocating 4KB per response can lead to significant memory overhead and GC pressure under high throughput. Since we only need to peek at the first 2 bytes to check for the gzip magic header, we can use bufio.NewReaderSize with a small buffer size (e.g., 16 bytes, which is the minimum buffer size in Go's bufio package) to dramatically reduce memory allocations.

Suggested change

	br := bufio.NewReader(resp.Body)
	br := bufio.NewReaderSize(resp.Body, 16)

[gemini-code-assist]

Similarly, we can use bufio.NewReaderSize with a small buffer size here to avoid allocating a 4KB buffer for each nested decompression level.

Suggested change

	br = bufio.NewReader(gz)
	br = bufio.NewReaderSize(gz, 16)

[clintonb]

Addressed the buffer-size feedback in 1766bd9: switched both bufio.NewReader calls to bufio.NewReaderSize(..., 16) via a named gzipPeekBufferSize constant, since this transport wraps every streamable response and only two bytes are peeked. 16 is bufio's minimum buffer size; large body reads bypass the buffer, so throughput is unaffected.