With the configuration file option “gatling.http.ahc.compressionEnabled” set to the default value of true, the http configuration option “acceptEncodingHeader” appears not to have any effect. If set to “deflate”, the actual HTTP request sent will still contain the header “Accept-Encoding: gzip, deflate”.
Setting it to “false” means the “Accept-Encoding” header contains whatever is defined in “acceptEncodingHeader” in the http configuration. However, if this includes “gzip” and if the server chooses to send a compressed response then the Gatling client appears to not correctly handle the response: in my brief testing the request stays in the ‘running’ state forever.
Ideally, the option would ensure that compression is supported, but not enforced. A single test could potentially require some requests to use compression, and others to not use compression. Would it be possible to define a test and a gatling configuration that supports this?
Gatling relies on AsyncHttpClient for handling Accept-Encoding.
Indeed, AHC ignores configured Accept-Encoding and automatically adds its own one when enabled.
Main Gatling goal is to mimics browsers/standard user agents, and this behavior suites 99,999% of the user-agents (you’re the first one it’s an issue for).
Then, mixing virtual users with compression enabled and others without is not possible at the moment. Not technically impossible, just unsupported. Until then, you’d have to run 2 different Gatling instances with different configuration, and merge the results (search for “Scaling out” in our documentation).
Before considering such a feature, could you elaborate about your use case, please?
Why do you need to mix virtual users with and without Accept-Encoding?
Why does “deflate” and “gzip, deflate” make that big a difference for you
Cheers,
It mostly caught us by surprise as the behaviour (i.e. ignoring the acceptEncodingHeader value) wasn’t as expected, so it could be a good idea to mention it in the documentation.
I can imagine some valid scenarios where someone wants to test requests from a realistic real-world set of user agents, including those that do and don’t support compression, especially if it’s likely that doing so would impact the load on the server. Actually we’re still getting fully acquainted with exactly what Gatling can do, and how to set it up to do it: is the http configuration a test-wide parameter anyway, so it isn’t possible to vary other items like user agent, accept-language, doNotTrack etc within a single test run?
But you’re perhaps right that it’s not going to be a common use case - and certainly at the moment this is a feature we could live without.
It mostly caught us by surprise as the behaviour (i.e. ignoring the
acceptEncodingHeader value) wasn't as expected, so it could be a good idea
to mention it in the documentation.
I've just fixed it in AsyncHttpClient but it will only be shipped in RC4,
not RC3:
I can imagine some valid scenarios where someone wants to test requests
from a realistic real-world set of user agents, including those that do and
don't support compression, especially if it's likely that doing so would
impact the load on the server. Actually we're still getting fully
acquainted with exactly what Gatling can do, and how to set it up to do it:
is the http configuration a test-wide parameter anyway, so it isn't
possible to vary other items like user agent, accept-language, doNotTrack
etc within a single test run?