http response header Content-Length
Problems encountered with the download file progress bar
==========================================================
This article addresses 4 questions
The relationship between gzip encoding and Content-Length
The relationship between block encoding and Content-Length
The file file has been gzip compressed on the server, so why does it return the Content-Length of the header or the size of the uncompressed image when requesting this image in node (the request method is head/get)?
Does the response header necessarily contain the Content-Length header?
Introduction to Content-Encoding gzip
Accept-Encoding and Content-Encoding are a pair of header fields used in HTTP to agree on "what encoding format is used to transmit the body".
working principle:
When the browser sends a request, it brings a list of content encoding formats it supports through Accept-Encoding, and the server selects one of them to encode the content. The encoded data is placed in the entity body, and then responded through Content-Encoding. The header indicates the selected format, and the browser gets the corresponding text and then decompresses it according to Content-Encoding.
Specific process:
The web server generates the original response message with the original Content-Type and Content-Length headers.
The content encoding server creates an encoded message. The encoded message has the same Content-Type and different Content-Length, and adds the Content-Encoding header.
The receiving program obtains the encoded message, decodes it, and obtains the original message.
The head method of http is exactly the same as the first line and header returned by the get method. The difference is that the response header of the get method will have the body, while the head method only returns the header in the response, not the body part, which allows the client to The header of the resource is checked without getting the actual resource.
The size of the Content-Length entity
在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首部。