JS bundle from CDN is not gzip encoded (most of the time)

[kumar303]

Describe the problem and steps to reproduce it:

• Open the Network panel
• Browse any page from prod (maybe in other envs, too?), such as https://code.addons.mozilla.org/en-US/

What happened?

• The JS bundle is 1.66MB and takes half a second to load. Example URL: https://addons-code-manager.cdn.mozilla.net/static/js/2.74a45ad5.chunk.js
• The headers show that the response is not gzip encoded even though the request asks for it to be

What did you expect to happen?

The bundle should be gzip encoded so that a smaller amount is transferred

Anything else we should know?

Here is how to reproduce an example request made by the browser:

curl -I 'https://addons-code-manager.cdn.mozilla.net/static/js/2.74a45ad5.chunk.js' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache'

Oddly, this sometimes returns a gzip encoded response but most of the time it does not.

I captured a log of responses (with headers) where only 2 out of 20 were gzip encoded.

┆Issue is synchronized with this Jira Task

[kumar303]

@bqbn is this something you could look into?

[bqbn]

Hmm, this is odd because I couldn't reproduce it using the provided command, I even tried this,

$ for ((i=0; i<50; i++)) ; do curl -I -s 'https://addons-code-manager.cdn.mozilla.net/static/js/2.74a45ad5.chunk.js' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' | egrep ^Content-Encoding; done
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip
Content-Encoding: gzip

I then tried it using https://www.webpagetest.org/, and the result also indicates that that js file is zipped [1].

And configuration wise, the Cloudfront distribution for this site is configured with "Compress Objects Automatically" [2], which means when viewer requests include Accept-Encoding: gzip in the headers, CloudFront should compress files of certain types (such as JS and CSS) and serve the compressed files.

[kumar303]

A couple minutes ago I saw your comment, ran the command, and verified that each response was indeed encoded.

However, I just ran it again and now the responses are no longer encoded. I added a counter to be sure:

$ for ((i=0; i<50; i++)) ; do curl -I -s 'https://addons-code-manager.cdn.mozilla.net/static/js/2.74a45ad5.chunk.js' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' | egrep ^Content-Encoding; echo $i; done
0
1
2
3
4
...
47
48
49

[kumar303]

Weird. Now it's back to encoded again.

We're tracking code-manager performance improvements in #1300 and it would be nice to figure out why the encoding intermittently fails.