I think https://api.stackexchange.com/docs/compression https://api.stackexchange.com/docs/compression is interesting and relevant here: > While our API is HTTP

I think https://api.stackexchange.com/docs/compression https://api.stackexchange.com/docs/compression is interesting and relevant here: > While our API is HTTP based, we chose to diverge from standard HTTP in one particular area. During normal operation, we guarantee that all responses are compressed, either with GZIP or DEFLATE. Read this line carefully: > If Content-Encoding is set on the response, use the specified algorithm. If it is missing, assume GZIP. So SO's API (but ONLY the API endpoint) does precisely what this website was doing. Just thought that was interesting to share. Their rationale: > There is a way to remain in compliance with the HTTP spec, which is to reject all requests that do not list "gzip" or "deflate" in their Accept-Encoding header. Unfortunately, this does not work in practice as far too many proxies (affecting ~1% of users in our experience) will strip out this header. > The motivation for this is simple, serving uncompressed content is a loss for all parties. Bandwidth is, in comparison to CPU time, exceptional[ly] expensive and severely limited on many devices. Its really a no-brainer to require compression accordingly. And then there's this hilarious tidbit at the end: > If response is not compressed this suggests a proxy between the user and us is intentionally decompressing content, or errors are occuring very early in processing requests. You can detect uncompressed content by checking for the appropriate magic numbers, assuming your library cannot detect this error for you.