HTTP协议学习笔记十一

实体和编码

Content-Length首部对于持久连接是必不可少的，如果响应通过持久连接传送，就可能有另一条HTTP响应紧随其后，客户端通过Content-Length首部就可以知道报文

在何处结束，下一条报文从何处开始。因为是持久的，所以客户端无法依赖连接关闭来判别报文的结束。

有一种情况下，使用持久连接时可以没有Content-Length首部，即采用分块编码。数据分为一系列的块来发送的，每块都有大小说明。哪怕服务器在生成首部的时候

不知道整个实体的大小，仍然可以使用分块编码传输若干已知大小的块。

确定实体主体长度的规则：

1.如果特定的HTTP报文类型中不允许带有主体，就忽略Content-Length首部。

2.如果报文中含有描述传输编码的Transfer-Encoding首部（不采用默认的HTTP“恒等”编码），那实体就应由一个称为“零字节块”的特殊模式结束，除非报文已经因连接

关闭而结束。如果没有Transfer-Encoding，那么Content-Length就是实体主体长度，如果有，就必须会略Content-Length，因为传输编码会改变实体主体的表示和传输

方式。

3.如果报文使用了multipart/byteranges（多部分/字节范围）媒体类型，而且没有用Content-Length首部指出实体主体的长度，那么多部分报文中的每个部分都要说明它

的自己的大小。

4.如果上面的规则都不匹配，。实体就在连接关闭的时候结束。实际上，只有服务器可以使用连接关闭来指示报文的结束。

内容编码过程，如图：

1.网站服务器生成原始响应报文，其中有原始的Content-Type和Content-Length首部。

2.内容编码服务器（也可能是原始服务器或下行的代理）创建编码后的报文，同样有Content-Type但Content-Length可能不同（比如主体被压缩了），

内容编码服务器再编码后的报文中增加Content-Encoding首部，这样接受的应用程序就可以进行解码了。

3.接受程序得到编码后的报文，进行解码，获得原始报文。

HTTP事务中Accept-Encoding首部，如图：

例：

Accept-Encoding: compress,gzip

Accept-Encondig: *

Accept-Encondig: compresss;q=0.5,gzip;q=1.0

Accept-Encondig: gzip;q=1.0,identity;q=0.5, *;q=0

客户端给每种编码附带Q值参数来说明编码的优先级。Q值的范围从0.0到1.0,0.0说明客户端不想接受所说明的编码，1.0则表示最希望使用的编码。

"*"表示“任何其他方法”,identity编码代号只能在Accept-Encoding首部中出现，客户端用它来说明相对于其他内容用编码算法的优先级。

传输编码与内容编码，如图：

分块编码，如图：

内容编码与传输编码的结合，如图：

传输编码的规则：

1.传输编码集合中必须包括“分块”。唯一的例外是使用关闭连接来结束报文。

2.当使用分块传输编码时，它必须是最后一个作用在报文主体之上的。

3.分块传输编码不能多次作用到一个报文主体上。

这些规则使得接收方能确定报文的传输长度。

范围请求，如图：

客户端的范围请求仅当客户端和服务器拥有文档的同一个版本时才有意义。