如果不受请求方法或响应状态代码的限制，请求和响应消息可能会传输实体。实体由实体头字段和实体 body 组成，尽管有些响应只包括实体头字段。

在本节中，发送方和接收方都指的是客户端或服务器，这取决于谁发送和谁接收实体。

7.1 实体头字段

实体头字段定义了关于实体 body 的元信息，如果没有 body，则定义了请求所标识的资源的元信息。有些元信息是可选的；有些可能是本规范的某些部分所必须的。

  1.        entity-header  = Allow                    ; Section 14.7
  2.                       | Content-Encoding         ; Section 14.11
  3.                       | Content-Language         ; Section 14.12
  4.                       | Content-Length           ; Section 14.13
  5.                       | Content-Location         ; Section 14.14
  6.                       | Content-MD5              ; Section 14.15
  7.                       | Content-Range            ; Section 14.16
  8.                       | Content-Type             ; Section 14.17
  9.                       | Expires                  ; Section 14.21
  10.                       | Last-Modified            ; Section 14.29
  11.                       | extension-header
  13.        extension-header = message-header

扩展头机制允许在不改变协议的情况下定义额外的实体头字段，但不能假定这些字段是可以被接收者识别的。未被识别的头字段应该被接收者忽略，并且必须由透明代理机构转发。

7.2 实体 body

与 HTTP 请求或响应一起发送的实体主体（如果有的话），其格式和编码由实体头字段定义。

  1. entity-body    = *OCTET

如第 4.3 节所述，只有当消息体存在时，实体 body 才会出现在消息中。实体 body 是通过解码任何可能被应用于确保安全和正确传输消息的 Transfer-Encoding 而从消息体中获得的。

7.2.1 类型

当一个实体 body 被包含在一个消息中时，该主体的数据类型是通过头字段 Content-Type 和 Content-Encoding 来确定的。这些定义了一个两层的、有序的编码模型：

  1. entity-body := Content-Encoding( Content-Type( data ) )

Content-Type 指定了基础数据的媒体类型。内容编码（Content-Encoding）可以用来表示应用于数据的任何额外的内容编码，通常是为了数据压缩，这是请求资源的一个属性。没有默认的编码。

任何包含实体 body 的 HTTP/1.1 消息都应该包括一个定义了该 body 的媒体类型的 Content-Type 头字段。如果且仅当媒体类型没有由内容类型字段给出时，接收者可以尝试通过检查其内容和/或用于识别资源的 URI 的名称扩展来猜测媒体类型。如果媒体类型仍然未知，接收方应将其视为 “application/octet-stream” 类型。

7.2.2 实体长度

消息的实体长度是在应用任何 transfer-codings 之前的消息体的长度。第 4.4 节定义了如何确定一个消息体的传输长度。