Problem
Go's transport adds Accept-Encoding: gzip and transparently decompresses — unless the caller sets the header explicitly, in which case decompression is disabled and the raw compressed bytes land in BodyBytes. All body assertions then run against gzip data.
Reproduction
Against a server that gzips when asked:
$ http-assert --assert-body '"status":"success"' http://127.0.0.1:8793/
[+] PASSED
$ http-assert -H 'Accept-Encoding: gzip' --assert-body '"status":"success"' http://127.0.0.1:8793/
[-] FAILED
- body: expected to match …
…
Content-Encoding: gzip
00000000 1f 8b 08 00 00 00 00 00 02 ff ← truncated hex dump, no explanation
Why it matters
The failure gives no hint that compression is the cause, and the truncation bug removes even the hex evidence. Setting Accept-Encoding explicitly is a normal thing to do when testing content negotiation.
Suggested fix
Detect a non-identity Content-Encoding on the response and either decompress before running body assertions, or emit an explicit warning:
Warning: response is gzip-encoded; body assertions run against compressed bytes
Problem
Go's transport adds
Accept-Encoding: gzipand transparently decompresses — unless the caller sets the header explicitly, in which case decompression is disabled and the raw compressed bytes land inBodyBytes. All body assertions then run against gzip data.Reproduction
Against a server that gzips when asked:
Why it matters
The failure gives no hint that compression is the cause, and the truncation bug removes even the hex evidence. Setting
Accept-Encodingexplicitly is a normal thing to do when testing content negotiation.Suggested fix
Detect a non-identity
Content-Encodingon the response and either decompress before running body assertions, or emit an explicit warning: