7 实体（Entity）
如果不被请求的方法或响应的状态码所限制，请求和响应消息都可以传输实体。 实体包括实体头域（entity-header）与实体主体（entity-body），而有些响应只包括实体头域（entity-header）。

在本节中的发送者和接收者是否是客户端或服务器，这依赖于谁发送或谁接收此实体。

7.1 实体报文域（Entity Header Fields）
实体（entity-header）头域定义了关于实体主体的的元信息，或在无主体的情况下定义了请求的资源的元信息。有些元信息是可选的；一些是必须的。

entity-header = Allow ; Section 14.7

| Content-Encoding ; Section 14.11

| Content-Language ; Section 14.12

| Content-Length ; Section 14.13

| Content-Location ; Section 14.14

| Content-MD5 ; Section 14.15

| Content-Range ; Section 14.16

| Content-Type ; Section 14.17

| Expires ; Section 14.21

| Last-Modified ; Section 14.29

| extension-header

extension-header = message-header

扩展头机制允许在不改变协议的前提下定义额外的实体头域，但不保证这些域在接收端能够被识别。未被识别的头域应当被接收者忽略，且必须被透明代理（transparent proxy）转发。

7.2 实体主体（Entity Body）
由HTTP请求或响应发送的实体主体（如果存在的话）的格式与编码方式应由实体的头域决定。

    Entity-body= *OCTET

如4。3节所述，实体主体（entity-body）只有当消息主体存在时时才存在。实体主体（entity-body）从消息主体通过传输译码头域（Transfer-Encoding）译码得到，传输译码用于确保消息的安全和合适的传输。

7.2.1类型（Type）
当消息包含实体主体（entity-body）时，主体的数据类型由实体头域Content-Type和Content-Encoding决定。这些头域定义了两层的顺序的编码模型：

    Entity-body：=Content-Encoding（ Content-Type（ data） ）

Content-Type指定了下层数据的媒体类型。Content-Encoding可能被用来指定附加的应用于数据的内容编码，经常用于数据压缩的目的，内容编码是请求资源的属性。没有缺省的译码。

任一包含了实体主体的HTTP/1.1消息都应包括Content-Type头域以定义实体主体的媒体类型。如果并且只有媒体类型没有通过 Content-Type头域指定时，接收者可能会尝试猜测媒体类型，这通过观察实体主体的内容并且/或者通过观察URI指定资源的扩展名。如果媒体类型 仍然不知道，接收者应该把类型看作”application/octec-stream”。

7.2.2实体主体长度（Entity Length）
消息的实体主体长度指的是消息主体在被应用于传输编码（transfer-coding）之前的长度。4.4节定义了怎样去确定消息主体的传输长度。