CODEWITHSUNDEEP
javascriptgzip
jeff-h
jeff-h

Reputation: 2639

When should JavaScript NOT be gzipped?

I've noticed that some big-name sites serve JavaScript that is compressed and some that is not compressed, on the same page load.

I also read that JavaScript shouldn't be gzipped when served over https. To back this up, I noticed that when serving jQuery from Google's CDN they only serve it compressed from HTTP, but not from HTTPS.

e.g. the first is compressed; the second is not.

http://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js"
https://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js"

However, if you pull jQuery from the Microsoft CDN over https:

https://ajax.aspnetcdn.com/ajax/jquery.mobile/1.3.2/jquery.mobile-1.3.2.min.js

it IS served compressed.

Examples of big sites that serve both compressed and uncompressed on the same page load, regardless of HTTPS or not:

So my question is: when should I gzip my JavaScript and when should I not?

Note, the question at Can you use gzip over SSL? And Connection: Keep-Alive headers is somewhat similar, in that the answers there explain under what circumstances compression should NOT be used under HTTPS. However, that's only half my question — some HTTP (not HTTPS) sites also compress some but not all of their javascript resources e.g. the Stackoverflow example mentioned above.

Upvotes: 15

Views: 5223

Answers (1)

slebetman
slebetman

Reputation: 113906

Initially I thought that it has something to do with old browser support as indeed IE6 and Netscape4 had bugs when handling compressed js files. But that had nothing to do with HTTPS. It was compression itself and server config files have long had conditional settings to not compress js files if an older browser is detected.

After some googling, it turns out that the issue is not with js. It is with HTTPS. You should not serve gzipped content over HTTPS/SPDY/HTTP2. There are two attacks that are possible when you serve gzipped content over HTTPS: CRIME and BREACH.

Both CRIME and BREACH attacks make use of the fact that gzipping data reduce their size in statistically predictable ways. Both attacks are able to extract cookies which, depending on how your site works, allows an attacker to login to user accounts.

So from your observation we can conclude that the google CDN is correctly configured.

However, do note how both attacks work: their ultimate aim is session hijacking. If you're downloading a js/css/gif file from a Microsoft server then your browser won't be sending your site's cookies along with the request (same-origin policy). So Microsoft can be forgiven for serving compressed js files on HTTPS.

Which means that you can serve compressed files over HTTPS! You just need to make sure those files come from a different domain to prevent CRIME and BREACH attacks from stealing your cookies.

Upvotes: 8

Related Questions