rpc: add gzip response compression

[amir-deris]

Summary

• Adds NewGzipHandler middleware (sei-tendermint/rpc/jsonrpc/server/gzip.go) that wraps any http.Handler with transparent gzip response compression using a sync.Pool-backed writer for allocation efficiency
• Wires the handler into the Tendermint RPC server (sei-tendermint/internal/rpc/core/env.go) and the Cosmos SDK API server (sei-cosmos/server/api/server.go)
• Compression is skipped for clients that do not advertise Accept-Encoding: gzip and for WebSocket upgrade requests (preserving http.Hijacker compatibility)

Test plan

• Unit tests in gzip_test.go cover compressed and uncompressed paths, pool reuse, and WebSocket passthrough
• Build passes: make build
• Smoke-test a node locally: confirm RPC responses are gzip-encoded when Accept-Encoding: gzip is sent (e.g. curl -H "Accept-Encoding: gzip" http://localhost:26657/status | file -)
• Confirm WebSocket connections (/websocket) are unaffected

link to design doc: Link

🤖 Generated with Claude Code

[cursor]

PR Summary

Low Risk
Transport-layer middleware only; clients without gzip headers get unchanged bodies, and WebSocket/hijack paths are explicitly bypassed.

Overview
Adds NewGzipHandler HTTP middleware that gzip-compresses responses when clients send Accept-Encoding: gzip (including * and q-values), sets Vary: Accept-Encoding on every response for cache safety, and uses a pooled writer at BestSpeed with a 1KB minimum size when Content-Length is known.

Compression is skipped for WebSocket upgrades, missing gzip acceptance, existing Content-Encoding, Transfer-Encoding: identity, bodyless statuses (204/304/1xx), and small known bodies; the wrapper still forwards http.Hijacker and http.Flusher.

The handler is wired into the Tendermint RPC server (after CORS), inspect RPC, and the Cosmos SDK API server (with or without unsafe CORS). Unit tests in gzip_test.go cover the main paths.

^{Reviewed by Cursor Bugbot for commit 8c8e7ac. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Jun 17, 2026, 6:57 PM

[codecov]

Codecov Report

❌ Patch coverage is 83.17757% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 58.09%. Comparing base (b54ff90) to head (8c8e7ac).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
sei-tendermint/rpc/jsonrpc/server/gzip.go	84.46%	12 Missing and 4 partials ⚠️
sei-cosmos/server/api/server.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3595      +/-   ##
==========================================
- Coverage   59.02%   58.09%   -0.93%     
==========================================
  Files        2211     2135      -76     
  Lines      182176   173276    -8900     
==========================================
- Hits       107522   100672    -6850     
+ Misses      64994    63679    -1315     
+ Partials     9660     8925     -735     

Flag	Coverage Δ
sei-chain-pr	42.30% <83.17%> (?)
sei-db	70.41% <ø> (ø)
sei-db-state-db	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
sei-tendermint/internal/inspect/rpc/rpc.go	61.53% <100.00%> (ø)
sei-tendermint/internal/rpc/core/env.go	78.36% <100.00%> (+0.12%)	⬆️
sei-cosmos/server/api/server.go	64.51% <0.00%> (-1.62%)	⬇️
sei-tendermint/rpc/jsonrpc/server/gzip.go	84.46% <84.46%> (ø)

... and 163 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bdchatham]

A few findings from an independent cross-review (systems / networking / security lenses) of the gzip middleware. The negotiation design is solid and client-side is backward-compatible — these three are origin-side concerns worth addressing before enabling on the public RPC/REST listeners. Line comments below.

[bdchatham]

CPU-DoS amplification on a public unauthenticated endpoint (level-6 compression, no size floor).

gzip.NewWriter defaults to DefaultCompression (zlib level 6). This middleware wraps the public Tendermint RPC (26657) and Cosmos REST (1317) and compresses multi-MB responses (block_results, paginated tx_search) inline on the serving goroutine. A ~200-byte unauthenticated request forces the node to gzip-level-6 megabytes of output — an asymmetric cheap-request/expensive-origin amplifier. The sync.Pool bounds allocation churn, not concurrency: a burst of N concurrent large-response requests pins N live level-6 writers (CPU + window state) at once. Since these origins CNAME directly to the ALB today (no CDN/WAF in the path per the design doc), there is no edge layer to absorb this.

Suggest:

• Use gzip.NewWriterLevel(io.Discard, gzip.BestSpeed) (level 1). It captures most of the byte savings — which is the stated egress-cost goal — at a fraction of the CPU.
• Add a minimum-size threshold (~1 KB) so tiny bodies skip compression; below that, gzip wastes CPU and can actually inflate the response.

[bdchatham]

The wrapper drops http.Hijacker; the WebSocket skip guard under-detects conformant upgrades.

gzipResponseWriter implements Header/Write/WriteHeader/Flush but not Hijack(), so wrapping the handler that serves CometBFT's /websocket route removes the http.Hijacker that gorilla's Upgrader.Upgrade requires (it asserts w.(http.Hijacker) and returns HTTP 500 otherwise). The only thing preventing that here is this skip — but strings.EqualFold(r.Header.Get("Upgrade"), "websocket") is an exact full-string match, while gorilla accepts a token list (Upgrade: websocket, foo, case-insensitive). A conformant-but-non-canonical or proxy-folded upgrade that also carries a default Accept-Encoding: gzip slips past this guard, gets wrapped, and 500s.

The in-tree CometBFT Go client is safe today (it dials single-token Upgrade: websocket with no Accept-Encoding), and TestNewGzipHandler_WebSocketPassthrough only covers that canonical case — so the gap is currently masked.

Suggest the idiomatic middleware fix: implement Hijack() on gzipResponseWriter, forwarding to the inner writer when it satisfies http.Hijacker (and don't compress a hijacked conn). That removes the dependency on header-sniffing entirely; keep this Upgrade skip as defense-in-depth. A regression test with Upgrade: websocket, foo + Accept-Encoding: gzip would lock in the fix.

[bdchatham]

Vary: Accept-Encoding is only emitted on the compressed path — fix before any CDN cutover.

Vary is added inside the compress branch, so responses that pass through uncompressed (no Accept-Encoding, q=0, pre-existing Content-Encoding, 204/304) emit no Vary at all.

This is not exploitable in the current direct-to-ALB topology (no shared cache to poison). But the design doc's later phase puts CloudFront in front, at which point a cache entry primed by an uncompressed request can be served to a client that sent Accept-Encoding: gzip (and vice versa) — and an attacker can choose which variant primes the entry. It's a latent bug that would ship baked into deployed nodes before the CDN lands.

Suggest:

• Emit Vary: Accept-Encoding on every response the middleware touches (compressed or not) — e.g. set it in NewGzipHandler before calling next, or unconditionally in the wrapper.
• Add here can also produce a duplicate Vary if an inner handler or CORS already set one. Read the existing value, ensure Accept-Encoding appears exactly once, and Set the result.

[bdchatham]

Follow-up: a few stream-lifecycle (layer-2) correctness nits. A corrupt/truncated stream is worse than a missed compression, so these are worth tightening.

[bdchatham]

Early-close corruption: after this closes+nils gz, any further Write falls to the w.gz == nil branch and appends raw bytes after the gzip footer. Simplest fix: drop this block and close once in the deferred close() (it never fires in the chunked/no-Content-Length common case anyway).

[bdchatham]

&& err == nil swallows the Close() (footer) error whenever gz.Write above errored, silently shipping a truncated stream — the evmrpc sibling does err = w.gz.Close() to surface it.

[bdchatham]

Double-Put risk: if a handler writes after ServeHTTP returns (streaming), this Put races the deferred close() Put and two requests can share one *gzip.Writer — removing the early-close block (above) eliminates it.

[bdchatham]

Streaming coalescing: with no Content-Length, Close() only runs here at the end, so an incremental/streaming route's output buffers until completion — confirm no non-WS streaming RPC/REST route exists, or exempt it.

[amir-deris]

Confirmed, no non-WS streaming routes exist. Every handler in this server (http_json_handler.go, http_uri_handler.go) marshals the full response into a byte slice and calls w.Write() once — no route writes incrementally or calls Flush() mid-response.

Also worth noting: gzipResponseWriter.Flush() already propagates gz.Flush() → the underlying http.Flusher, so any future streaming route that calls Flush() periodically would get correct incremental delivery without needing any changes here.

[bdchatham]

On testing — I'd lean on a single-process round-trip harness here rather than adding more httptest.NewRecorder cases. The recorder is actually why the current suite stays green while the lifecycle issues above survive: it buffers Write calls into memory, so it never exercises real chunked transfer-encoding, real Flush timing, Content-Length handling, or a real http.Hijacker. Swap it for httptest.NewServer and you get all of that over a loopback connection — still one process, still fast — with a real client decoding the far end.

The core invariant is just bytes in == bytes out, for every shape of payload. One helper serves a body through NewGzipHandler, the client reads and gzip-decodes the response, and we assert it matches the original. Then sweep sizes that each mean something: 0 and 1 byte, sizes straddling net/http's ~4KB write buffer (4095 / 4096 / 4097) to force real chunking, and a ~1MB body — run once with Content-Length set and once without, since those are genuinely different paths through the writer.

The one subtlety worth calling out: decode with gzip.Reader.Multistream(false) and then assert the next read returns io.EOF. That's what actually catches the early-close corruption — if raw bytes get appended after the gzip footer, a plain io.ReadAll(gzip.NewReader(...)) silently ignores them and the test passes anyway. That trailing-byte check is the difference between a feel-good round-trip and one that fails on the real bug.

Two more the recorder can't express: a concurrent variant (a couple hundred goroutines, each asserting its own payload comes back) run under -race to validate the pool reuse, and a streaming case where the handler writes a chunk, flushes, then blocks — the client should see chunk one before chunk two is written. If gzip buffers instead of flushing, that test just deadlocks, which is a clear enough signal.

The swallowed Close() error and the Hijacker case are the exceptions — those want a small custom ResponseWriter (fault injection / interface assertion) rather than a round-trip — but everything else falls out of that one harness.

Happy to write the harness up if it's useful. And dm me if you have questions on any of this.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 5 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 007a8ff. Configure here.}

[amir-deris]

Addressed feedbacks!