Origin: #99 (comment)
Summary
When using the BlazeMeter HTTP sampler (Jetty client), compressed responses differ from what users see in the browser DevTools or in the standard JMeter HTTP Request sampler (Apache HttpClient4): Content-Encoding is missing and Content-Length reflects the decompressed body size instead of the on-the-wire values.
Steps to reproduce
- Send a request to an endpoint that returns
Content-Encoding: gzip (or br, zstd) with a compressed JSON body.
- Compare response headers in:
- Browser Network tab
- JMeter HTTP Request (HttpClient4) + View Results Tree
- BlazeMeter HTTP sampler + View Results Tree
Expected behavior
Aligned with HTTP Request / HTTPHC4Impl (see JMeter Bug 59401):
- Response body in
HTTPSampleResult is decompressed (suitable for assertions, JSON extractors, etc.).
- Response headers in the sample result still show wire compression metadata when the server compressed the payload, e.g.:
Content-Encoding: gzip (HTTP/2 may use lowercase header names)Content-Length matching the compressed size on the wire
Actual behavior
Jetty’s HTTP client transparently decompresses the response (documented behavior). After decoding:
Content-Encoding is removed (or not shown as in the browser).Content-Length is updated to the decompressed size (e.g. 238 bytes instead of 643).
Example reported by users:
| Source |
content-encoding |
content-length |
| Browser |
gzip |
238 (compressed) |
| BlazeMeter HTTP (Jetty) |
(missing) |
643 (decompressed) |
Root cause
- Jetty
HttpClient ContentDecoder decompresses the body and updates/removes compression-related headers (same class of behavior as Apache ResponseContentEncoding).
- JMeter’s HTTPHC4Impl works around this by backing up
Content-Length, Content-Encoding, and Content-MD5 before decompression and restoring them when building the HTTPSampleResult.
- The BlazeMeter HTTP plugin did not implement an equivalent restore step.
Origin: #99 (comment)
Summary
When using the BlazeMeter HTTP sampler (Jetty client), compressed responses differ from what users see in the browser DevTools or in the standard JMeter HTTP Request sampler (Apache HttpClient4):
Content-Encodingis missing andContent-Lengthreflects the decompressed body size instead of the on-the-wire values.Steps to reproduce
Content-Encoding: gzip(orbr,zstd) with a compressed JSON body.Expected behavior
Aligned with HTTP Request /
HTTPHC4Impl(see JMeter Bug 59401):HTTPSampleResultis decompressed (suitable for assertions, JSON extractors, etc.).Content-Encoding: gzip(HTTP/2 may use lowercase header names)Content-Lengthmatching the compressed size on the wireActual behavior
Jetty’s HTTP client transparently decompresses the response (documented behavior). After decoding:
Content-Encodingis removed (or not shown as in the browser).Content-Lengthis updated to the decompressed size (e.g. 238 bytes instead of 643).Example reported by users:
content-encodingcontent-lengthgzipRoot cause
HttpClientContentDecoder decompresses the body and updates/removes compression-related headers (same class of behavior as ApacheResponseContentEncoding).Content-Length,Content-Encoding, andContent-MD5before decompression and restoring them when building theHTTPSampleResult.