nginx和squid 2.5的gzip压缩问题

最近发现一个奇怪的问题，对于nginx在后端，squid在前端的架构，squid输出的页面并未进行过压缩。而将hosts指向nginx机器时，发现页面确实是压缩的。

后来在网上查了很久的资料，上说squid并不能很好的支持http1.1，所以压缩的页面通过它之后就会不压缩了。又过了两天跟同事提起该事时，他提醒apache2的deflate模块打开时，通过squid输出也是压缩的。所以又要回头来查找问题了，其中问题的焦点仍然在 http1.1和1.0上。

我尝试将apache输出的头和nginx输出的头进行比较，然后一个一个在nginx里头add_header和 proxy_hide_header，花了几个小时，调试到最后，问题依旧。

然后我觉得问题出在我提取头时使用了IE浏览器，所以发送的都是 http1.1请求，取得的结果和squid访问后端的结果并不是一致的。

我于是又找了台机器，使用curl -0来调试。此次调试终于发现了问题：

curl --header "Accept-Encoding: gzip, deflate" -D x -0 http://apache

上面的命令输出结果是乱码，证明是压缩的。

curl --header "Accept-Encoding: gzip, deflate" -D x -0 http://nginx

上面的命令输出结果是明码，证明是没压缩。

终于发现了差别！！！

但是根据第二个命令执行后，nginx也能返回压缩结果了由这些现象可以得出，squid确实是使用的http1.0向后面取数据的，apache居然能支持 http1.0下的压缩？貌似http1.0下没有压缩吧。于是去查了资料，发现http1.0确实是可以压缩的。

那么nginx支不支持1.0的压缩？到nginx.net去查查。查到gzip_module时，居然给找到了一条完完整整的配置语句：

gzip_http_version

syntax : gzip_http_version 1.0|1.1
default: gzip_http_version 1.1
context: http, server, location

Turns gzip compression on or off depending on the HTTP request version.
When HTTP version 1.0 is used, the Vary: Accept-Encoding header is not set. 
As this can lead to proxy cache corruption, consider adding it with add_header. 
Also note that the Content-Length header is not set when using either version. 
Keepalives will therefore be impossible with version 1.0, while for 1.1 it is handled
by chunked transfers.

加到nginx.conf，很好，这时squid是可以返回压缩内容了。