Investigating intermittent lack of gzip for CSS/Font files from Fastly

fastly-gzip-issues.md

Occasionally CSS and font files served from www.etsy.com via Fastly (and only Fastly) are not gzipped. None of our other CDNs appear to have this issue.

We have seen this effect via Zoompf alerts, Catchpoint tests, and can reproduce it with curl (again, intermittently):

curl -k -H "Host: www.etsy.com" -H "Accept-Encoding:gzip" -v "https://global-ssl.fastly.net/assets/dist/css/base.20141024160711.edge.css" -v > /dev/null

Compare to origin:

curl -k -H "Host: www.etsy.com" -H "Accept-Encoding:gzip" -v "https://origin-www.etsy.com/assets/dist/css/base.20141024160711.edge.css" -v > /dev/null

Things we have tried:

• Purging the entire Fastly cache for www - on 10/27/14 at ~5PM UTC
• Testing all origin servers to confirm that they all send the right Content-Encoding header and Vary: Accept-Encoding
• Purging a specific asset that was occasionally uncompressed

Other information:

• This only happens for CSS and fonts on www.etsy.com, we have never seen it for JS on site.etsystatic.com
• We only have a single origin defined with fastly, so all requests, for any domains, get sent to the same place
• Fastly normalizes Accept-Encoding headers to improve cache hit rate (blog post here)
• There is no pattern around the cache nodes where this occurs. We have seen it on multiple ISPs, in multiple regions, as far apart as LA and Atlanta.
• When looking at the response headers in Catchpoint, you have to scroll the window to see all of them (this sounds stupid, but it's super non-obvious in the UI).