IE6 不支持HTTP协议的动态压缩chunked方式

临近端午节放假前夕，准备上线一个项目的登录和注册功能，判断用户登录是否成功是通过询问一个登录服务器login.baofeng.net,访问方式如下：

 //检测是否登录;
function isLoginIn(fn, i) {
  if(cookie.get("LoginIn") == 1) {
     showBannerUserInfo();
  } else {
  var url = "http://login.baofeng.net/?a=checklogin&info=1&callback=" + fn + "&reqid=" + i;
  jsonRequest(url);
  }
}; 

//检测登录回调
function checkLoginIn(j, i) {
   if(j.status == 1) {
     cookie.put("LoginIn", 1); //1表示登录
     cookie.put("bf_sid", j.bf_sid); //存bf_sid
     cookie.put("username", j.userinfo.username);
     cookie.put("email", j.userinfo.email);
     showBannerUserInfo();
   } else {
   showBannerUserLogin();
   }
}; 

可是在上线时，一件奇怪的事情发生了，内测服务器都OK的功能，放到外网服务器就在IE6浏览器出现问题。


排除法：

将外网服务器的代码全部搬移到内网测试服务器上，功能全部OK，再放到线上服务器，还是出问题。

众人拾材火焰高：

本着没病不死人的原则，大家继续定位问题，发现当前这个脚本的JS没有完全加载完成，加载到某一段就断掉了，发现问题就似乎有了一线生机，通过抓包工具发现当前这个base.js的返回code是200，但没有Content－Length的值，奇怪为什么服务器会不返回这个值呢。通过搜索得知为了提高网页展现的性能，Nginx服务器提供了Gzip模块，该模块采用动态压缩chunked方式提高网页返回的效率，服务器的nginx的配置如下：

#开启gzip模块，要求安装gzip 在运行./config时要指定
gzip on;
gzip_min_length  1100;
gzip_buffers    4 8k;
gzip_types      text/plain;
output_buffers  1 32k;
postpone_output  1460;

上述模块的参数说明：[url=http://www.5gme.com/space-6-do-blog-id-57096.html]http://www.5gme.com/space-6-do-blog-id-57096.html[/url]


通过反复测试终于发现了这个问题的真正原因：

本次功能新增的一台登录验证服务器也是采用Nginx对外提供登录确认的服务，该服务也是同样采取的gzip模块进行压缩，将此服务器的gzip模块注销掉，IE6下不能判定登录注册状态的问题解决了。


通常，HTTP协议中使用Content-Length这个头来告知数据的长度。然后，在数据下行的过程中，Content-Length的方式要预先在服务器中缓存所有数据，然后所有数据再一股脑儿地发给客户端。

如果要一边产生数据，一边发给客户端，WEB 服务器就需要使用"Transfer-Encoding: chunked"这样的方式来代替Content-Length。


"Transfer-Encoding: chunked"是这样编码的：

HTTP头
\r\n
\r\n      --连续的两个\r\n之后就是HTTP体了
16进制值代表的数据长度
\r\n
上面所指的数据长度
\r\n    --每段数据结束后，以\r\n标识

16进制代表的第二段数据
\r\n
XX长度的数据
\r\n

………… (反复通过这样的方式表示每次传输的数据长度)

0      --数据结束部分用0表示，然后是连续的两个\r\n
\r\n
\r\n

由于IE6不支持chunked方式的动态压缩，所以只能放弃对IE6用户的压缩，调整Nginx的配置：

#开启gzip模块，要求安装gzip 在运行./config时要指定
gzip on;
gzip_min_length  1100;
gzip_buffers    4 8k;
gzip_types      text/plain;
gzip_disable    "MSIE [1-6] \.";
output_buffers  1 32k;
postpone_output  1460;