临近端午节放假前夕,准备上线一个项目的登录和注册功能,判断用户登录是否成功是通过询问一个登录服务器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;
上述模块的参数说明:
http://www.5gme.com/space-6-do-blog-id-57096.html
通过反复测试终于发现了这个问题的真正原因:
本次功能新增的一台登录验证服务器也是采用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;
分享到:
相关推荐
1. **动态内容生成**:当服务器不能预先知道响应体的总长度时,如动态生成的网页,chunked编码可以提供一种灵活的方式发送数据。 2. **流量控制**:通过分块发送,服务器可以根据网络状况调整每个块的大小,从而优化...
HTTP chunked编码是一种在HTTP协议中用于处理大文件或流式传输数据的方式。它允许服务器在不知道确切内容长度的情况下发送响应。这种方式对于那些在生成过程中才能确定大小的动态内容非常有用,例如,从数据库中实时...
这种方式特别适用于服务器无法提前知道响应体总长度的情况,例如动态生成的内容。 在Boost.ASIO中处理chunked编码,你需要实现一个解析器来逐块接收和处理数据。这通常涉及读取响应头,找到“Transfer-Encoding: ...
HTTP 1.1 的 Chunked 编码是一种特殊的传输编码方式,用于在不知道数据总长度的情况下传输动态生成的内容。根据 RFC 2616 的 3.6.1 节描述,chunked 编码通过将消息体分成一系列的块(chunk),每个块都有自己的大小...
一个对chunked编码进行解码的例子,通过java socket实现发送http请求,对gzip压缩的消息体进行解码处理。
Chunked编码是HTTP协议中的一个特性,主要用在HTTP 1.1版本中,用于处理不确定长度的数据传输。这种编码方式允许发送方在不知道消息总长度的情况下,将数据分块发送,每一块都伴随着其大小的标识,最后一块则使用一...
5. **支持多种编码方式**:如Chunked Transfer Encoding用于分块传输大文件,gzip编码用于压缩数据,提高传输效率。 综上所述,HTTP协议通过RFC文档进行标准化,其发展历程从HTTP/1.0到HTTP/1.1,逐步完善了网络...
HTTP Chunked编码是一种在HTTP协议中传输大体积数据的方式,主要用在HTTP 1.1版本中,因为HTTP 1.0不支持内容长度未知的响应。Chunked编码的引入解决了服务器无法预先知道响应体总长度的问题,允许数据分块发送,每...
此外,为了提高效率和兼容性,我们可能需要实现HTTP缓存机制、支持多种编码方式(如gzip压缩)、处理重定向等。这些都需要对HTTP协议有深入的理解,并且在C语言中实现这些功能可能会涉及到复杂的逻辑和低级别的系统...
内容编码(如gzip压缩)用于减小数据量,传输编码(如chunked分块传输)则用于将数据分成多个块进行发送,这对于大文件传输或者数据流传输非常有用。 6. 嵌入式系统中的实现 在嵌入式系统中实现HTTP协议,需要注意...
这种方式减少了延迟,但并非所有服务器和代理都支持。 3. **分块编码(Chunked Transfer Coding)**:解决了HTTP 1.0中无法处理大文件传输的问题。分块编码允许服务器将大文件分成多个小块发送,客户端可以逐步接收...
HTTP1.1协议引入了一种名为`CHUNKED`编码的方式,用于处理那些在发送时无法预先知道内容长度的情况。这种编码方式对于动态生成的、流式传输的内容尤其有用,因为它允许服务器在不知道整个响应体确切大小的情况下就...
netty案例,netty4.1中级拓展篇十一《Netty基于ChunkedStream数据流切块传输》源码 ...
在HTTP协议中,`Transfer-Encoding: chunked`是一种用于分块传输编码的方式,常用于服务器无法预先知道响应体总长度的情况。这种方式将响应体分成多个块(chunks),每一块都有一个大小标识,最后以一个零长度的块...
还有分块编码(Chunked Transfer Coding)机制,允许服务器在不知道响应大小的情况下发送数据。 HTTP/1.1的错误码是其重要的一部分,用于指示请求是否成功或者遇到了什么问题。比如,200 OK表示请求成功,404 Not ...
3. **分块编码(Chunked Transfer Coding)**:允许服务器在不知道确切响应大小的情况下发送数据,这对于大型文件的传输非常有用,因为服务器可以立即开始发送数据,而无需等到整个文件加载完毕。 4. **内容协商...
《HTTP: The Definitive Guide》中还详细讲解了HTTP缓存机制、代理服务器、重定向、错误处理、编码技术(如chunked传输编码和gzip压缩)等内容,以及与Web服务器、应用程序开发、API设计等相关的话题。 总的来说,...
使用方式:ajax(url, method, data, header, options) 请求chunked接口:例子: ajax(url, method, data, header, { enableChunked: true, chunkReceived(data){ ... } }) 请求普通的http接口: ajax(url, ...
- Chunked编码:用于分块传输实体主体,适应不确定长度的响应。 - Persistent Connections(持久连接):HTTP/1.1默认开启,允许复用TCP连接,减少连接建立和关闭的开销。 - Pipelining(管道化):在同一持久连接上...