Response body is not properly decompressed when gzip is true

[RandScullard]

I ran into a problem where my capture was not working, and I debugged through Artillery and found that the problem was that it was trying to parse the compressed data. If I set gzip: false on my post, the captures work fine, but if I set gzip to true, they fail.

The problem seems to be in this block of code in HttpEngine.prototype._handleResponse:

  let body = '';
  if (maybeCallback) {
    res.on('data', (d) => {
      body += d;
    });
  }

When I put a breakpoint on the line body += d; with gzip set to true and a compressed HTTP response, I see that d contains a big block of compressed data. It looks like you may need to use a different technique with the got package to access the decompressed response body.

For now, my workaround is to set gzip to false. This way, the server does not send a compressed response so the problematic code path is avoided.

[hassy]

It looks like Got added a response.body property since the HTTP engine was originally upgraded from Request.js to Got, so we can probably get rid of that bit of code, and rely on Got to decompress gzipped responses before we run captures on them.

Thank you for looking into it @RandScullard!

[hassy]

Fixed in v1.7.2

[wcaquino]

I had a similar issue using the artillery version 2.0.0-21. However, based on this thread, when I downgraded the Artillery version to 1.7.2, my script worked as expected. Has anything changed since then?