Transfer-Encoding头字段列出了与已经（或将要）应用于有效载荷主体的传输编码序列相对应的传输编码名称，以便形成消息主体。传输编码被定义在第4节。

     Transfer-Encoding = 1#transfer-coding

Transfer-Encoding类似于MIME的Content-Transfer-Encoding字段，他被设计用于通过7位传输服务（RFC2045的第6节）安全的传输二进制数据。但是，安全传输对于8位清理传输协议而言具有不同的重点。在HTTP的情况下，Transfer-Encoding主要是为了精确划定一个动态生成的有效载荷，并区分仅用于传输效率或安全性的有效载荷编码与所选资源的特征。

接收者必须能够解析分块传输编码（4.1节），因为在有效载荷体的尺寸预先未知的情况下构成消息的时候它扮演了一个关键的角色。发送者不得对消息体使用分块超过一次（即将一个已经分块的消息进行分块是不允许的）。如果任何非分块（chunked）的传输编码被用于请求的有效载荷体，发送者必须将chunked作为最后的传输编码以确保消息被正确构成。如果任何非chunked的传输编码被用于响应的有效载荷体，发送者必须将chunked作为最后的传输编码或通过关闭连接终止消息。

例如，Transfer-Encoding: gzip, chunked 表示有效载荷体使用gzip编码进行压缩，然后在组成消息体时分块使用了分块编码。

与Content-Encoding（RFC7231的3.1.2.1节）不同，Transfer-Encoding是一个消息的属性而不是表示形式。任何沿着请求/接收链的接收者可能解码接收到的传输编码，或者假设对Transfer-Encoding字段值做出相应的改变，则向消息体添加额外的传输编码。额外的编码参数信息可以由其他头字段提供，它们不在本规范中定义。

Transfer-Encoding可能在HEAD请求的响应或者GET请求的304（未修改）响应（RFC7232中4.1节）中发送，二者都不包含消息主体。这将指示如果请求是无条件的GET请求，源服务器将会对消息主体应用的传输编码。但这不是必要的，因为任何处于响应链上的接收者（包括源服务器），当他们不需要的时候会移除传输编码。

服务器不得在任何1xx（信息）或204（无内容）状态码的响应中发送Transfer-Encoding头字段。服务器不得在CONNECT请求（RFC7231的4.3.6节）的2xx（成功）响应中发送Transfer-Encoding头字段。

Transfer-Encoding在HTTP/1.1中被加入。一般认为申明仅支持HTTP/1.0的实现将不能理解如何处理传输编码的有效载体。客户端不得发送包含Transfer-Encoding的请求，除非它知道服务器将会处理HTTP/1.1（或之后版）的请求；这种知晓的形式可能来自具体的用户配置或者由先前接收到的响应的版本信息。服务器不得发送包含Transfer-Encoding的响应，除非对应的请求表明是HTTP/1.1（或之后）的版本。

服务器接收到一个带有不能理解的传输编码的消息时，应该响应一个501（未实现）。