3 ms·
The main CSS file they're using is https://www.w3.org/2008/site/css/minimum https://www.w3.org/2008/site/css/minimum. If you download this with `curl 'https://w
by nneonneo 4y ago
The main CSS file they're using is https://www.w3.org/2008/site/css/minimum https://www.w3.org/2008/site/css/minimum. If you download this with `curl 'https://www.w3.org/2008/site/css/minimum https://www.w3.org/2008/site/css/minimum' -H 'Accept-Encoding: gzip, deflate, br'`, you see that it starts with 03 D7 86 1F 8B 08 08 and ends with 25 10 91 4D 7B 30 00 00 03. This is a brotli metablock header (03 D7 86: length = 3503 bytes, uncompressed), followed by a gzip header (1F 8B 08 08: signature, compression=deflate, filename present), and ends with a gzip trailer (25 10 91 4D 7B 30 00 00: crc32, size of file) and finally an empty brotli metablock header (03).
So, what's happening is that they're serving gzip files from their server (which is hinted by the "content-location: minimum.css.gz" response header), which are being compressed again using brotli somewhere else (e.g. at a reverse proxy).
- infogulch 4y agoMy guess is they've been serving their css file direct from disk with no content encoding header, but browsers rolled their eyes and decoded it anyway (do they do that?). But now it's changed to serve behind a reverse proxy which isn't so forgiving and recompresses it with brotli (does it even reduce the size?) and that's too much for the browser to infer implicitly. Fin.
- nneonneo 4y agoWorth noting: if you're not seeing the Brotli header, it's probably because something (e.g. your browser) is transparently decoding the declared Content-Encoding (which is `br` for Brotli). That'll yield raw gzip data. In this case, your browser or other user agent has already applied Content-Encoding, so they aren't going to do it again.