http响应头首部Content-Length

http响应头首部Content-Length

下载文件进度条遇到的问题

==========================================================

 本文讲述4个问题

 

gzip编码与Content-Length的关系

分块编码与Content-Length的关系

file文件已经在服务端进行gzip压缩，那为何在node中用request请求这张图片时（请求的方法为head/get）返回头首部Content-Length还是未压缩前的图片大小？

响应头一定会包含Content-Length首部吗？ 

 
 内容编码gzip介绍

Accept-Encoding和Content-Encoding是HTTP中用来对「采用何种编码格式传输正文」进行协定的一对头部字段。

 

工作原理：

 

浏览器发送请求时，通过Accept-Encoding带上自己支持的内容编码格式列表，服务端从中挑选一种用来对内容编码，编好码的数据就放在实体主体中，再通过Content-Encoding响应头指明选定的格式，浏览器拿到相应正文后再依据Content-Encoding进行解压。

 

具体过程：

 

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

内容编码服务器创建编码后的报文，编码后的报文有同样的Content-Type和不同的Content-Length，同时增加了Content-Encoding首部。

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

 

http的head方法与get方法返回的首行和首部完全相同，不同的是get方法的响应头中会有主体，而head方法在响应中只返回首部，不会返回主体部分，这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。

 

Content-Length 实体的大小

 

在http的协议中Content-Length首部告诉浏览器报文中实体主体的大小。这个大小是包含了内容编码的，比如对文件进行了gzip压缩，Content-Length就是压缩后的大小，而不是原始大小（这点对我们编写服务器非常重要）。除非使用了分块编码，否则Content-Length首部就是带有实体主体的报文必须使用的。使用Content-Length首部是为了能够检测出服务器崩溃而导致的报文截尾，并对共享持久连接的多个报文进行正确分段.

 

另外Content-Length首部对于长连接是必不可少的，长连接代表在连接期间会有多个http请求响应在排队，而服务器不能够关闭连接，客户端只能通过Content-Length知道一条报文在哪里结束，下一条报文在哪里开始。

 

除非使用了分块编码Transfer-Encoding: chunked，否则响应头首部必须使用Content-Length首部。（HTTP1.1必须支持chunk模式。因为当不确定消息长度的时候，可以通过chunk机制来处理这种情况。也就是有chunk就不能有content-length 。） [摘自http权威指南]

 

传输编码和分块编码

分块编码把「报文」分割成若干个大小已知的块，块之间是紧挨着发送的，这样就不需要在发送之前知道整个报文的大小了。（也意味着不需要写回Content-Length首部了）

 

当使用持久连接时，在服务器写主体之前，必须知道它的大小并在Content-Length首部中发送。如果服务器动态创建内容，可能在发送之前无法知道主体大小，分块编码就是为了解决这种情况。服务器把主体逐块发送，说明每一块的大小。服务器再用大小为0的块作为结束块。，为下一个响应做准备。

 

再回过头看请求file文件服务器的图片时响应头的首部信息发现了这个首部：Transfer-Encoding: chunked

  

这也说明了这个图片请求的响应是采用分块编码的传输方式，采用这种传输方式进行响应时，没必要带上Content-Length这个首部信息。因为即使带上了也是不准确的。再回过头看上述file图片的响应头中确实没有Content-Length首部。

 

对于在发送HTTP头部前，无法计算出Content-Length的HTTP请求及回复（例如WEB服务端产生的动态内容），可以使用分块传输，使得不至于等待所有数据产生后，再发送带有Content-Length的HTTP头部，而是将已经产生的数据一块一块发送出去。普通的静态页面、图片之类的基本上都用不到这个。

HTTP BODY数据成连续的块传输，每块数据的最开始处，指明了该数据块的大小，随后则是CRLF，数据，及结尾CRLF：

《HTTP权威指南》

http://www.mamicode.com/info-detail-75113.html

 

 

 HTTP1.1采用了持久的连接，也就是一次TCP的连接不马上释放，允许许多的请求跟响应在一个TCP的连接上发送，所以客户机与服务器需要某种方式来标示一个报文在哪里结束和在下一个报文在哪里开始。简单的方法是使用呢content-length，但这只有当报文长度可以预先判断的时候才起作用，而对于动态的内容或者在发送数据前不能判定长度的情况下，可以使用分块的方法来传送编码。