On Mon, Aug 29, 2011 at 4:28 PM, Herbert Valerio Riedel <h...@gnu.org> wrote: > 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 <g...@gregorycollins.net> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe