Content-Encoding: br, or Brotli compression with JMeter

Update: JMeter 3.3 now includes Brotli compression out of the box

I am working on a load test for a customer and I ran into a very weird problem where I was not able to paginate on their search results page. I use the JQuery/CSS Post Processor on JMeter to extract the “next page” URL, but for some reason, on this page, I could not extract it. I opened up the View Results Tree listener and found the request that was supposed to extract that URL. The response data had this:

No other requests were having this problem. I was wondering if the problem was a bad content type or something but it wasn’t Next up was an incorrect content-encoding, such as having content gzipped, but lacking the content-encoding header. But I was wrong. In checking the sampler result I saw the problem:

HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/html; charset=UTF-8
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Vary: Accept-Encoding,Cookie
content-encoding: br
transfer-encoding: chunked

I had never seen a content encoding of br before. It turns out that it is Brotli. It looks like it’s fairly new. It only came out in 2015. It also doesn’t look like, at the moment, JMeter supports it. I use Firefox to build my JMeter tests and Firefox supports it, but JMeter doesn’t (apparently the current nightly releases do, but I haven’t tested them). And because I sampled the test from JMeter, these were the request headers:

Accept-Language: en-US,en;q=0.5
Upgrade-Insecure-Requests: 1
Accept-Encoding: gzip, deflate, br
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Since the current JMeter release does not support it, it looks like, for the time being, you need to go into your HTTP Header Manager for any requests that use a post processor and change the accept-encoding header to gzip, deflate.