Problem
A body arriving as Content-Encoding: br is not decoded, so the three body assertions refuse rather than run:
$ 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
--assert-ok, --assert-status and --assert-header* are unaffected, so this is a gap rather than a failure — but no body assertion can be made against such a response at all.
Why it matters
Brotli is the default for most CDNs and for a good deal of static content, and a caller testing content negotiation with -H 'Accept-Encoding: br' is doing something entirely ordinary. Today that caller has no way to assert on the payload.
Why it is not supported today
There is no brotli decoder in the Go standard library, and the tool currently has three dependencies in total — viper was deleted in #54 specifically to cut the count. Adding one is a deliberate trade, not an oversight.
Proposed
Either:
- Take the dependency.
github.com/andybalholm/brotli is pure Go and the usual choice. Weigh it against the dependency budget and the binary size, which the release notes track.
- Decode only when a decoder is present, via a build tag, so the default binary stays dependency-free and a
brotli-tagged build handles it. Costs a second release artifact.
Whichever way it goes, the wiring already exists: decoders in main.go maps a content coding to a function, and decodeBody reports an unknown one by name. Supporting br is one map entry plus the decoder.
Related
Problem
A body arriving as
Content-Encoding: bris not decoded, so the three body assertions refuse rather than run:--assert-ok,--assert-statusand--assert-header*are unaffected, so this is a gap rather than a failure — but no body assertion can be made against such a response at all.Why it matters
Brotli is the default for most CDNs and for a good deal of static content, and a caller testing content negotiation with
-H 'Accept-Encoding: br'is doing something entirely ordinary. Today that caller has no way to assert on the payload.Why it is not supported today
There is no brotli decoder in the Go standard library, and the tool currently has three dependencies in total — viper was deleted in #54 specifically to cut the count. Adding one is a deliberate trade, not an oversight.
Proposed
Either:
github.com/andybalholm/brotliis pure Go and the usual choice. Weigh it against the dependency budget and the binary size, which the release notes track.brotli-tagged build handles it. Costs a second release artifact.Whichever way it goes, the wiring already exists:
decodersinmain.gomaps a content coding to a function, anddecodeBodyreports an unknown one by name. Supportingbris one map entry plus the decoder.Related