On Mon, Aug 29, 2011 at 4:28 PM, Herbert Valerio Riedel
On Mon, 2011-08-29 at 13:21 +0200, Gregory Collins wrote:
A web server should not be setting "Content-encoding: gzip" on a .tar.gz file.
Why not? From RFC2616 compliant servers I'd expect a .tar.gz file to have the Content-* headers provide meta-information about the content[1], e.g.
Content-Type: application/x-tar Content-Encoding: gzip Transfer-Encoding: chunked
The way I would interpret this is: this MIME body is a TAR file which has been gzip-encoded for the purpose of efficiency in transmission. When I ask the library for the body contents as an octet stream, I would expect to get the TAR file contents, uncompressed. This is how it works when you send text/html with "Content-Encoding: gzip", I don't understand why it should be different with a .tar.gz file. If you wanted the MIME body to be passed through unmolested (i.e. you expect the octet stream to actually be in gzip-compressed TAR format), I would expect that you set "Content-Type: application/x-tgz" without a Content-Encoding. But that's just my interpretation both of standard practice and of the spec.
If I want to detach the gzip encoding from the "content" (or "entity"), I'd move it to the Transfer-Encoding header[2], e.g.:
Content-Type: application/x-tar Transfer-Encoding: gzip, chunked
As Michael mentioned, that isn't how those headers are interpreted.
G
--
Gregory Collins