> This boils down to an ambiguity found in the early days of HTTP The RFC is clear on this, different Transfer-Encoding is only for the transfer and does not a

> This boils down to an ambiguity found in the early days of HTTP The RFC is clear on this, different Transfer-Encoding is only for the transfer and does not affect the identity of the resource, while different Content-Encoding does affect the identity of the resource. Its not sure who did it first, but either Browsers or Web Servers started using the Content-Encoding header (which means, "this file is always compressed" like a tar.gz, user agent not meant to uncompress) with the meaning of Transfer-Encoding (which means, the file is not compressed, compression is just applied for the sake of the transfer and the user agent needs to uncompress first). This is a violation of the HTTP spec. This fuckup resulted in big confusion and now requires an annoying amount of workarounds: - E-Tag re-generation [1] - Ranges and Compression are not usable together - Browsers's "Resume Download" feature removed - RFC-compliant behavior being a bug [2] - Some corporate proxies are still unpacking tarballs on the fly, breaking checksum verification Contrast this to eMail, which has the Encodings correctly sorted out, while using the same RFC822 encoding technique as HTTP. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=39727 https://bz.apache.org/bugzilla/show_bug.cgi?id=39727 [2] https://serverfault.com/questions/915171/apache-server-causes-tar-gz-files-to-download-as-uncompressed-tarballs-still-nam https://serverfault.com/questions/915171/apache-server-cause... tl;dr: HTTP Standard is not being implemented correctly