HTTP协议的chunked编码

一般情况HTTP的Header包含Content-Length域来指明报文体的长度。如:

有时候服务生成HTTP回应是无法确定消息大小的,比如大文件的下载,或者后台需要复杂的逻辑才能全部处理页面的请求,这时用需要实时生成消息长度,服务器一般使用chunked编码。

在进行Chunked编码传输时,在回复消息的Headers有transfer-coding域值为chunked,表示将用chunked编码传输内 容。使用chunked编码的Headers如下(可以利用FireFox的FireBug插件或HttpWatch查看Headers信 息,HttpWatch还可以查看chunked的个数):

chunked采用以下方式编码:

Chunked-Body=*chunk
"0"CRLF
footer
CRLF
chunk=chunk-size[chunk-ext]CRLF
chunk-dataCRLF
hex-no-zero=<HEXexcluding"0">
chunk-size=hex-no-zero*HEX
chunk-ext=*(";"chunk-ext-name["="chunk-ext-value])
chunk-ext-name=token
chunk-ext-val=tokenquoted-string
chunk-data=chunk-size(OCTET)
footer=*entity-header

编码使用若干个Chunk组成,由一个标明长度为0的chunk结束,每个Chunk有两部分组成,第一部分是该Chunk的长度和长度单位(一般不
写),第二部分就是指定长度的内容,每个部分用CRLF隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容,是一些没有写的头部内容。

from:http://www.cnblogs.com/zhaozhan/archive/2010/08/24/1807639.html

时间: 2024-10-26 17:23:16

HTTP协议的chunked编码的相关文章

HTTP1.1中CHUNKED编码解析(转载)

HTTP1.1中CHUNKED编码解析 一般HTTP通信时,会使用Content-Length头信息性来通知用户代理(通常意义上是浏览器)服务器发送的文档内容长度,该头信息定义于HTTP1.0协议RFC  1945  10.4章节中.浏览器接收到此头信息后,接受完Content-Length中定义的长度字节后开始解析页面,但如果服务端有部分数据延迟发送吗,则会出现浏览器白屏,造成比较糟糕的用户体验. 解决方案是在HTTP1.1协议中,RFC  2616中14.41章节中定义的Transfer-E

HTTP协议之chunk编码(分块传输编码)

分块传输编码(Chunked transfer encoding)是超文本传输协议(HTTP)中的一种传输数据机制,同意HTTP由应用server发送给client应用( 一般是网页浏览器)的数据能够分成多个部分.分块传输编码仅仅在HTTP协议1.1版本号(HTTP/1.1)中提供. 通常,HTTP应答消息中发送的数据是整个发送的.Content-Length消息头字段表示数据的长度.数据的长度非常重要,由于client须要知道哪里是应答消息的结束,以及兴许应答消息的開始.然而,使用分块传输编码

http协议中的编码和解码

http://www.csdn1 2 3.com/html/itweb/20130730/29422_29378_29408.htm ****************************** 一.字符集与文字编码简介 1. 计算机如何显示文字 我们知道,计算机是以二进制的“形式”来保存和处理数据的,也 就是说,不管我们使用键盘进行输入,还是让计算机去读取一个文本文件,计算机得到的原始内容是一些二进制序列,当需要对这些二进制序列进行显示时,计算机 会依照某种“翻译机制”(也就是编码方式),取到

【协议分析】HTTP响应头中的2种编码方式介绍

HTTP 1.1中有两个实体头(Entity-Header)直接与编码相关,分别为Content-Encoding和Transfer-Encoding.    先说Content-Encoding, 该头表示实体已经采用了的编码方式.Content-Encoding是请求URL对应实体(Entity)本身的一部分.比如请求URL为 http://host/image.png.gz时,可能会得到的Content-Encoding为gzip.Content-Encoding的值是不区分大小写的,目前

HTTP协议扫盲(九 )HTTP1.1响应的Transfer-Encoding=chunked方式

一.背景知识 1.chunked编码 分块传输编码(Chunked transfer encoding)是只在HTTP协议1.1版本(HTTP/1.1)中提供的一种数据传送机制.以往HTTP的应答中数据是整个一起发送的,并在应答头里Content-Length字段标识了数据的长度,以便客户端知道应答消息的结束. 2.好处 对于动态生成的应答内容来说,内容在未生成完成前总长度是不可知的.因此需要先缓存生成的内容,再计算总长度填充到Content-Length,再发送整个数据内容.这样显得不太灵活,

http 编码chunked

之前针对这个也不是很关注,这个chunked在nginx上是默认开启的,但是在apache上没有,所以当切换服务器的时候,同时遇到了这个问题,发现数据内容存在乱码. 定位我就知道应该是http header的问题,但是具体是什么也不是很清楚. 仔细查阅发现,这个chunked编码. http以trunked编码方式传输的数据表示规则 一般HTTP通信时会使用是Content-Length头信息性来指定小,但是有时候无法确定信息大小,就要使用trunked编码动态的提供body内容的长度. 进行C

HTTP协议头部与Keep-Alive模式详解(转)

转自:http://a280606790.iteye.com/blog/1095085 http1.1 中怎么打开持久连接,怎么关闭,怎么传输数据(确定本次数据是否传输完毕) 1.什么是Keep-Alive模式? 我们知道HTTP协议采用“请求-应答”模式,当使用普通模式,即非KeepAlive模式时,每个请求/应答客户和服务器都要新建一个连接,完成 之后立即断开连接(HTTP协议为无连接的协议):当使用Keep-Alive模式(又称持久连接.连接重用)时,Keep-Alive功能使客户端到服

模拟http请求 带 chunked解析办法一

今天在干坏事抓取别人页面时候遇到一个问题,平时我们在post数据后,大不了要求提交cookie,但是今天这个测试了N遍不需要coookie都行的,但是抓取到的始终是乱码,怎么解析都不行.于是自己又把cookie和一大堆header给加上,还是同样的问题,于是开始郁闷了.PHP脚本不行,但是同样的提交浏览器上面就行,这个是怎么回事呢?于是开始分析能看到的数据,终于看到一个特别的地方,我们平时请求数据的时候都会在header里面看到一个 Coontent-Length: xxxx 这个是表示这次发送

HTTP协议头部与Keep-Alive模式详解

1.什么是Keep-Alive模式? 我们知道HTTP协议采用“请求-应答”模式,当使用普通模式,即非KeepAlive模式时,每个请求/应答客户和服务器都要新建一个连接,完成 之后立即断开连接(HTTP协议为无连接的协议):当使用Keep-Alive模式(又称持久连接.连接重用)时,Keep-Alive功能使客户端到服 务器端的连接持续有效,当出现对服务器的后继请求时,Keep-Alive功能避免了建立或者重新建立连接. http 1.0中默认是关闭的,需要在http头加入"Connectio