关于HTTP1.1中chunked编码详解

Chunked-Body（块正文）= chunk（块）               chunk-size [ chunk-extension ] \r\n

                                                                                           chunk-data \r\n

                                              last-chunk（最后块）           0 \r\n
                                               trailer（尾部）                     *entity-header \r\n
                                              CRLF                                    \r\n

f56[chunk-extension]\r\n ---------------------------->chunk长度，用十六进制数表示，f56表示下面数据块有3926字节

………………\r\n ------------------------------------>3926字节的数据(数据二进制)

400[chunk-extension]\r\n----------------------------->又一个chunk十，六进制数400表示下面数据块有1024字节

………………\r\n ------------------------>1024字节的数据(数据二进制)

0\r\n-------------------------------------------------------->最后块

trailer\r\n------------------------------------------------->尾部

\r\n--------------------------------------------------------->整个块正文结束

 

 

chunk-extension可选，由通信双方自行确定，如果接收端不理解它的含义可以忽略

结构为于【； chunk-ext-name =chunk-ext-val】（注意：前边有一个分号）类似于content-type中有时会出现的 ; charset=GBK结构

chunk-ext-name 和chunk-ext-val 都是在IANA字符集注册机构注册过的标记

 

 

trailer是附加在尾部的附加头域

       trailer = *（entity-header CRLF）
entity-header 是包含在Trailer头域的（下边会详细讲解），Trailer头域被用来指明哪些头域被包含在块编码（chucked）的尾（trailer）

如果服务器要用块传输编码进行响应，以下条件至少一条为真，否则它不能包含尾部（trailer）
a）如果此响应的请求包括一个TE头域（下边会详细讲解），并且它指明了传输编码中的“trailers”是可接受的，并且响应的传输编码（transfer-coding）是块编码时。

b）如果服务器是响应的源服务器，1.接收端接收块传输编码响应但不会去理会响应的尾部（trailer）2.源服务器是可以接受1这种方式。换句话说，尾部（trailer）可能会在到达客户端时被丢弃的可能性源服务器原意接受。

此要求防止了一种互操作性的失败，当消息被一个HTTP/1.1（或更高版本）代理（proxy）接收并且转到一个HTTP/1.0的接收端的时候。  

 

TE头域（请求）

TE请求头域指明客户端可以接受哪些传输编码（transfer-coding）的响应，和是否愿意接收块（chunked）传输编码响应的尾部（trailer）。类似于Accept-Encoding,但是Accept-Encoding应用于内容编码（content-coding）。

如果出现关键字“trailers”，那么它指明客户端愿意接受（chunked）传输编码响应的尾部（trailer）。 此关键字为传输编码（transfer-coding）值而保留，但它本身不代表一种传输编码。
举例：

       TE:

       TE: trailers, deflate;q=1

TE请求头域仅适用于立即连接。所以无论何时，只要在HTTP/1.1消息中存在TE头域，连接头域（Connection header filed）中就必须指明。

通过TE头域，服务器能利用下述规则来测试传输编码（transfer-coding）是否是可被客户端接受的：
块（chunked）传输编码总是可以接受的（注：所以不需要在TE头域里指定块（chunked）传输编码，因为请求端总是可以接收块传输编码）。如果在TE头域里出现关键字“trailers”，那么客户端指明它愿意接受块（chunked）传输编码响应里的尾部（trailer）。这意味着客户端或者正在声明所有的下游客户端愿意接收块（chunked）传输编码响应里的尾部（trailer），或者声明它愿意代表下游接收端去尝试缓存响应。
 
只要是出现在TE头域里的传输编码都是可被请求端接受的，除非此传输编码跟随的qvalue值为0（qvalue为0表明是“不可接受的”）

如果在TE头域里有指明多个传输编码是可接受的，那么传输编码（transfer-coding）的qvalue值越大，表示此传输编码的是最容易被被接受的。块传输编码的qvalue值为1。

如果TE头域值是空的或者TE头域没有出现在消息里，那么服务器只能认为块（chunked）传输编码的响应是请求端可以接受的。没有传输编码的消息总是可接受的。

 

 

Trailer（响应）
Trailer头域指明了在以块（chunked）传输编码消息里的尾部（trailer）里用到的头域。

如果一个http/1.1消息包含了一个Trailer头域，说明它利用了块（chunked）传输编码并且编码里的尾部（trailer）不为空。这样做是为了使请求端知道块（chunked）传输编码响应消息尾部（trailer）有哪些头域。

如果具有块传输编码的消息，没有Trailer头域存在，则此消息的尾部（trailer）将不能包括任何头域。3.6.1节展示了块传输编码的尾部（trailer）的利用限制。

Trailer头域中指示的消息头域不能包括下面的头域：
.Transfer-Encoding
.Content-Length
.Trailer