for HTTP 1.1 specifies how web servers must indicate encoding transformations using the Content-Encoding header. Although on the surface, Content-Encoding (e.g., gzip, deflate, compress) and Content-Type(e.g., x-application/x-gzip) sound similar, they are, in fact, two distinct pieces of information. Whereas servers use Content-Type to specify the data type of the entity body, which can be useful for client applications that want to open the content with the appropriate application, Content-Encoding is used solely to specify any additional encoding done by the server before the content was transmitted to the client. Although the HTTP RFC outlines these rules pretty clearly, some web sites respond with "gzip" as the Content-Encoding even though the server has not gzipped the content.

Our testing has shown this problem to be limited to some sites that serve Unix/Linux style "tarball" files. Tarballs are gzip compressed archives files. By setting the Content-Encoding header to "gzip" on a tarball, the server is specifying that it has additionally gzipped the gzipped file. This, of course, is unlikely but not impossible or non-compliant.

Therein lies the problem. A server responding with content-encoding, such as "gzip," is specifying the necessary mechanism that the client needs in order to decompress the content. If the server did not actually encode the content as specified, then the client's decompression would fail.

 

-----------------------------------来自RFC2616--------------------------------------

 

When an entity-body is included with a message, the data type of that   body is determined via the header fields Content-Type and Content-   Encoding. These define a two-layer, ordered encoding model:       entity-body := Content-Encoding( Content-Type( data ) )   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. There is   no default encoding.   Any HTTP/1.1 message containing an entity-body SHOULD include a   Content-Type header field defining the media type of that body. If   and only if the media type is not given by a Content-Type field, the   recipient MAY attempt to guess the media type via inspection of its   content and/or the name extension(s) of the URI used to identify the   resource. If the media type remains unknown, the recipient SHOULD   treat it as type "application/octet-stream".