Am 07.05.2018 um 18:59 schrieb Vladimir Sitnikov:
Antonio>Do you have an idea of the performance impact?
I'm afraid, it is inevitable. One of the further enhancements is might be
sending pre-compressed *.gz files
Option 1 seems better for me
It looks so. As far as I know, request body compression is not specified in
the standard, so using JMeter-specific "header" to trigger the compression
might be the right thing to do.
For instance:
X-JMeter-Content-Compression: gzip
Later it could be improved to:
X-JMeter-Content-Compression: gzip; compression_level=1 vs
X-JMeter-Content-Compression: gzip; compression_level=9
If we use just `Content-Encoding` to trigger the behavior, then it would be
hard to evolve.
+1
If we use Content-Encoding, we could break other scripts, that have
already compressed their payload.
That means "body compression" might deserve its own set of UI checkboxes,
however it looks like the case is rare (neither HTTP/1 nor HTTP2 specify
body compression), so we might be fine to keep that behind "trigger header"
to avoid UI clutter.
Right, nothing stops us from adding the ui or preprocessor or other
mechanism after we introduce the header trigger.
Regards,
Felix
Vladimir
