# Accept-Encoding header and compressionEnabled configuration **URL:** \ **Category:** Gatling (Open-Source)\ **Created:** [September 1, 2014, 3:44am UTC](https://community.gatling.io/t/accept-encoding-header-and-compressionenabled-configuration/1346 "2014-09-01T03:44:41Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Andy\_M](https://avatars.discourse-cdn.com/v4/letter/a/82dd89/32.png) [@Andy\_M](https://community.gatling.io/u/Andy_M)\ **Post date:** [September 1, 2014, 3:44am UTC](https://community.gatling.io/t/accept-encoding-header-and-compressionenabled-configuration/1346/1 "2014-09-01T03:44:41Z")
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? (This is using gatling-2.0.0.RC2) ---
**Author:** ![Excilys](https://avatars.discourse-cdn.com/v4/letter/e/8797f3/32.png) [@Excilys](https://community.gatling.io/u/Excilys)\ **Post date:** [September 1, 2014, 7:44am UTC](https://community.gatling.io/t/accept-encoding-header-and-compressionenabled-configuration/1346/2 "2014-09-01T07:44:55Z")
Hi Andy, 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? 1. Why do you need to mix virtual users with and without Accept-Encoding? 2. Why does “deflate” and “gzip, deflate” make that big a difference for you Cheers, Stéphane ---
**Author:** ![Andy\_M](https://avatars.discourse-cdn.com/v4/letter/a/82dd89/32.png) [@Andy\_M](https://community.gatling.io/u/Andy_M)\ **Post date:** [September 1, 2014, 10:40am UTC](https://community.gatling.io/t/accept-encoding-header-and-compressionenabled-configuration/1346/3 "2014-09-01T10:40:52Z")
Thanks for the quick response Stéphane. 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. ---
**Author:** ![Excilys](https://avatars.discourse-cdn.com/v4/letter/e/8797f3/32.png) [@Excilys](https://community.gatling.io/u/Excilys)\ **Post date:** [September 1, 2014, 12:00pm UTC](https://community.gatling.io/t/accept-encoding-header-and-compressionenabled-configuration/1346/4 "2014-09-01T12:00:34Z")
> 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: > > > Instead of forcefully setting "gzip, deflate" > 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? Not at the moment. I'll think of something. ---
**Author:** ![Andy\_M](https://avatars.discourse-cdn.com/v4/letter/a/82dd89/32.png) [@Andy\_M](https://community.gatling.io/u/Andy_M)\ **Post date:** [September 2, 2014, 12:40am UTC](https://community.gatling.io/t/accept-encoding-header-and-compressionenabled-configuration/1346/5 "2014-09-02T00:40:23Z")
Many thanks for the very quick fix! And looking forward to seeing if/how multiple http profiles can be supported. ---
**Author:** ![Excilys](https://avatars.discourse-cdn.com/v4/letter/e/8797f3/32.png) [@Excilys](https://community.gatling.io/u/Excilys)\ **Post date:** [September 2, 2014, 8:13am UTC](https://community.gatling.io/t/accept-encoding-header-and-compressionenabled-configuration/1346/6 "2014-09-02T08:13:09Z")
I have opened a new feature request: [https://github.com/gatling/gatling/issues/2162](https://github.com/gatling/gatling/issues/2162)