On Mon, Aug 29, 2011 at 5: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
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
[1]: See RFC2616 sec7.2.1: "Content-Type specifies the media type of the underlying data. Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that are a property of the requested resource."
[2]: See RFC2616 sec4.3: "Transfer-Encoding is a property of the message, not of the entity, and thus MAY be added or removed by any application along the request/response chain."
"chunked" is the only valid transfer-encoding[1], while gzip must be specified on the content-encoding header[2]. For a simple example of these two, look at the response headers from Haskellers[3] in something like Chrome developer tools. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6 [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5 [3] http://www.haskellers.com/