http协议 Content-Encoding Content-Length Transfer-Encoding 三头部的理解

HTTP协议中，如何理解Content-Encoding Content-Length Transfer-Encoding这三个头部之间的关系？
最近看nginx代码处理http协议，按照自己的理解，整理如下:

• Content-Encoding

HTTP BODY的内容编码，其中gzip只是内容编码的一种；

• Content-Length

HTTP BODY的长度，该长度是内容编码后的长度。该头部可以用来检测报文是否被截取尾部，即是否接收到完整的报文。在Http 1.0以前版本中,Content-Length字段可有可无。由于早期的版本中无长连接Keep-Alive,每个TCP只有一个Request- Response，Server端在发送完Response后就关闭TCP连接释放资源。在没有Content-Length头部时，客户端根据该连接是 否关闭来检测报文是否接收完毕。该判定方法存在的问题是，不能区分TCP连接的关闭是由于Server端正常处理完毕而关闭TCP连接，还是Server 端进程崩溃而导致的TCP连接关闭。另外，到1.1版本后，有了HTTP长连接，即一个TCP上连接上可以处理多个Request-Response，这 就彻底不能通过TCP连接关闭来判断报文是否接收完毕，需要依靠Content-Length都字段。

Transfer-Encoding

传输编码，为了方便传输而进行的编码。使用了传输编码如:chunked，它能自解释是否报文传输完毕，此时不需要Content-Length字段了来检测了，而且，如果既有Content-Length头部和Transfer-Encoding: chunked， Content-Length头部必须忽略，必须根据Transfer-Encoding: chunked来进行检测。

总结：

1. 响应码为 1xx(临时响应),204(无消息体)，304(未修改)相应或者head请求，则直接忽视掉消息实体内容。

2. 同时有Content-Encoding和Transfer-Encoding，则优先采用Transfer-Encoding里面的方法来找到对应的长度。比如说Chunked模式。