feat(compress): Decode brotli and zstd response bodies

[korya]

Problem

A CDN response cannot have its payload asserted on, because brotli and zstd bodies are never decoded.

decoders knew only gzip and deflate, so --assert-body, --assert-body-eq and --assert-jq refused by name while --assert-ok, --assert-status and --assert-header* carried on:

$ http-assert --assert-body '"status":"success"' https://cdn.example.com/
- body: response is br-encoded and was not decoded: no decoder for "br"; gzip and deflate are supported

Brotli is the default for most CDNs and zstd is a registered coding (RFC 8878) being switched on across them. Testing content negotiation with -H 'Accept-Encoding: br' is an ordinary thing to do, and it was the one thing this tool could not follow through on.

Solution

Add both decoders — andybalholm/brotli and klauspost/compress/zstd — and derive the "supported" list from the decoder map so it can no longer drift.

The dependency question, with numbers instead of adjectives

The count was cut to three deliberately when viper went (#54), so both tickets asked for this to be weighed rather than assumed. Nothing tracked binary size, so it was measured at release flags (-trimpath -ldflags="-s -w", CGO_ENABLED=0):

	Size	Δ
Before	7.38 MB	—
+ brotli	7.62 MB	+233 KB
+ brotli + zstd	7.80 MB	+419 KB (+5.7%)

Both modules bring zero transitive dependencies. #78 worried that klauspost/compress is "considerably larger than a brotli-only package" — true of the repository, not of the binary: only the zstd package links, so it costs 186 KB, less than brotli.

The build-tag alternative was rejected because it fits this project's distribution badly. Released binaries are how the tool is used, so a tag either ships releases that cannot decode the thing the change is about, or doubles the artifacts to ten and makes the user pick.

The part the tickets called "one map entry"

The suite used br throughout as its stand-in for an encoding with no decoder here — which stopped being true of it. That role moves to compress (LZW): RFC 9110 still registers it, effectively nothing serves it, and unlike br and zstd it is not a plausible candidate for support later, so the fixtures should stay honest this time.

The e2e brotli fixture was also fake by construction — "the bytes are not real brotli because nothing in the suite could produce them, and the CLI never gets far enough to care." With a decoder the CLI does get far enough: fed to a real decoder those bytes give unexpected EOF. /brotli now serves genuine brotli, /zstd genuine zstd, and /brotli-corrupt covers a failure that was unreachable before — a body claiming br that is not br.

Verification

New e2e tests cover decoding, --assert-jq over a decoded body, and that the Content-Encoding header still reports what arrived. They were mutation-checked: with the two map entries removed they fail, so they are testing the decoders rather than the fixtures.

Manually, both codings were decoded from streams produced by the reference implementations — brotli 1.2.0 and zstd 1.5.7 — not only by Go's own writers, which is the interop the test suite cannot prove on its own. Brotli additionally end-to-end against jsdelivr and the npm registry, asserting the payload and the Content-Encoding header in the same run.

Other Changes

• The failure now reads no decoder for "compress"; br, deflate, gzip, zstd are supported, built from the map, with an e2e test pinning it.
• Package docs, --help and README updated; the README paragraph promising br and zstd "are not supported yet" is gone.
• No visual change — CLI only.

Closes #77
Closes #78

Related:

• -H 'Accept-Encoding: gzip' silently breaks all body assertions #27

🤖 Generated with Claude Code