> What happened to the Content-Encoding: gzip header though? > I still don’t know where the Content-Encoding: gzip header went! Did Cloudflare remove it? Did m

> What happened to the Content-Encoding: gzip header though? > I still don’t know where the Content-Encoding: gzip header went! Did Cloudflare remove it? Did my webhost stop serving it for some reason? I have no idea! Anyway, my site seems to work again (I think/hope?) and I thought this was kind of a fun excursion into HTTP headers. I would presume that Cloudflare's HTTP client doesn't send an 'Accept-encoding: gzip' header, and , likely, they don't support caching the 'Content-encoding:' header. I would expect this because Cloudflare's purpose is to optimize your traffic as much as possible, so to do that, they want to negotiate the least optimized content from your upstream server. Requesting unoptimized content from upstream will minimize your server's performance utilization at the coat of increased traffic utilization. However, that small increase in traffic utilization is offset by Cloudflare's content caching. Also, when Cloudflare makes that initial request due to a cache miss, there's a downstream user expecting that content. If Cloudflare wants to minimize the time of that request, as they want to do for all requests, so if they get gzipped content, then they need to decompress, store the content in cache, and, if 'accept-encoding:gzip' is present, then re-gzip the content. They are trying to minimize that turn around by not having to decompress content which the author's rewrite rules, essentially, broke the HTTProtocol contract. I'm sure it's incredibly rare to encounter one, but this very issue is expected behavior for HTTP/1.0 clients as they don't support gzip.