http中Content-Length的解读
Content-Length首部通知浏览器报文中实体主体的巨细。这个巨细是包含了内容编码的，比方对文件进行了gzip紧缩，Content-Length就是紧缩后的巨细（这点对我们编写效劳器非常重要）。除非运用了分块编码，不然Content-Length首部就是带有实体主体的报文必须运用的。运用Content-Length首部是为了能够检查出效劳器溃散而导致的报文截尾，并对同享耐久衔接的多个报文进行准确分段。
1）检查截尾
HTTP的前期版本选用封闭衔接的方法来划定报文的完毕。可是，没有Content-Length的话，客户端无法区别到底是报文完毕时正常的封闭衔接还是报文传输中由于效劳器溃散而导致的衔接封闭。客户端需求经过Content-Length来检查报文截尾。
报文截尾的疑问对缓存代理效劳器来说尤为重要。假如缓存效劳器收到被截尾的报文却没有识别出截尾的话，它可能会存储不完整的内容并屡次运用他来供给效劳。缓存代理效劳器一般不会为没有显式Content-Length首部的HTTP主体做缓存，以此来减小缓存已截尾报文的危险。
2）Content-Length与耐久衔接
Content-Length首部关于耐久衔接是必不可少的。假如呼应经过耐久衔接传送，就可能有另一条HTTP呼应紧随其后。客户端经过Content-Length首部就能够知道报文在何处完毕，下一条报文从何处开端。由于衔接是耐久的，客户端无法依靠衔接封闭来判别报文的完毕。
有一种状况，运用耐久衔接能够没有Content-Length首部，即选用分块编码（chunked encoding）时。在分块编码的状况下，数据是分为一系列的块来发送的，没块都有巨细说明。哪怕效劳器在生成首部的时分不知道整个实体的巨细（一般是由于实体是动态生成的），依然能够运用分块编码传输若干已知巨细的块。
点击链接加入群聊三群：751529538
点击链接加入群聊二群：376877156
点击链接加入群聊【路由器交流群：622891808已满】
本站附件分享，如果附件失效，可以去找找看
饿了么红包
