http 响应头里 没有 或者有 content-length 的几种可能性

对于http的请求返回结果要进行内容的长度校验主要有两种方式，二者互斥使用

1.客户端在http头(head)加Connection:keep-alive时，服务器的response是Transfer-Encoding:chunked的形式，通知页面数据是否接收完毕，例如长连接或者程序运行中可以动态的输出内容，例如一些运算比较复杂且需要用户及时的得到最新结果，那就采用chunked编码将内容分块输出。

2.除了如1所述之外的情况一般都是可以获取到Content-Length的。

在HTTP协议中，Content-Length用于描述HTTP消息实体的传输长度the transfer-length of the message-body。在HTTP协议中，消息实体长度和消息实体的传输长度是有区别，比如说gzip压缩下，消息实体长度是压缩前的长度，消息实体的传输长度是gzip压缩后的长度。

在具体的HTTP交互中，客户端是如何获取消息长度的呢，主要基于以下几个规则：

其实后面几条几乎可以忽视，简单总结后如下：

1、Content-Length如果存在并且有效的话，则必须和消息内容的传输长度完全一致。（经过测试，如果过短则会截断，过长则会导致超时。）

2、如果存在Transfer-Encoding（重点是chunked），则在header中不能有Content-Length，有也会被忽视。

3、如果采用短连接，则直接可以通过服务器关闭连接来确定消息的传输长度。（这个很容易懂）

结合HTTP协议其他的特点，比如说Http1.1之前的不支持keep alive。那么可以得出以下结论：

1、在Http 1.0及之前版本中，content-length字段可有可无。

我总结我的例子 如果 要是 js css html 这样的文件的话 会返回 contengt-length 字节 前提是 nginx 里的gzip off 如果是on 的话 返回 chunk

执行的如果是 动态 脚本的话， 还是返回chunk 前提是 content:keep-alive 如果不是长连接的话 返回的头里面没有content-leght （）