最近发现一个奇怪的问题，对于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
上面的命令输出结果是明码，证明是没压缩
终于发现了差别！！！
但是：
curl --header "Accept-Encoding: gzip, deflate" -D x 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是可以返回压缩内容了。
头疼几天的问题，终于得到解决。 教学网 eduyo.com
------------------------------------------------------------------
另：gzip_vary需要设为on，系统需要/usr/lib/zlib.a，zlib1.2.3安装
./configure --shared --prefix=/usr
./configure --prefix=/usr
编译两次都安上
------------------------------------------------------------------
nginx0.7.3版本以下需要加上：
add_header Vary Accept-Encoding;
强制nginx发送vary
否则squid会在得到非压缩版本后认为nginx不支持压缩，然后将缓存的非压缩版本持久不更新，这样会诡异的出现某个链接长期返回非压缩版本的情况，通常是首页。
------------------------------------------------------------------
nginx0.7.3以下的版本强制加上Vary后，会出现缓存几秒钟就过期的诡异现象，所以只能使用0.7.3以上的版本才能解决问题。