[网络协议]HTTP - 实体首部

由于请求和响应报文中都可能包含实体部分，所以在这两种类型的报文中都可能出现这些首部。

实体首部

• Content-Type: 实体中所承载对象的类型。
• Content-Language: 与所传送对象最配的人类语言。
• Content-Encoding: 对象数据所做的任意转换（比如：压缩）
• Content-Length: 所传送实体主体的长度或大小。
• Cache-Control: 指出应该如何缓存改文档。
• Expires: 实体数据将要失效的日期时间。
• Last-Modified: 所传输内容在服务器上创建或最后修改的日期时间。
• ETag: 这份文档特定实例的唯一验证码。
• Content-Location: 一个备用位置，请求时可通过它获得对象。
• Allow: 该资源所允许的各种请求方法，例如：GET 和 HEAD。
• Content-Range: 如果这是部分实体，这个首部说明它是整体的哪个部分。
• Content-MD5：实体主体的校验和。

Content-Type

Content-Type 首部字段说明了实体主体的 MIME 类型。Content-Type 首部还支持可选的参数来进一步说明内容的类型。charset（字符）参数就是个例子，它说明把实体中的比特转换为文本文件中字符的方法。

//请求和响应实体中字段相同
Content-Type: text/html;charset=iso-8859-4

Content-Language

实体的 Content-Language 首部字段描述实体的目标受众语言。

//请求实体
Accept-Language: fr
Accept-Charset: iso-8859-1

//响应实体 响应实体没有 charset 首部
Content-Type: text/html;charset=iso-8859-1
Content-Language: fr

Content-Encoding

HTTP 定义了一些标准的内容编码类型，并允许用扩展编码的形式增添更多的编码。Content-Encoding 首部就用这些标准化的代号来说明编码时使用的算法。

gzip、compress以及 deflate 编码都是无损压缩算法，用于减少传输报文的大小，不会导致信息损失。这些算法中，gzip 通常是效率最高的，使用最为广泛。

//请求实体
Accept-Encoding: gzip,compress
Accept-Encoding: 
Accept-Encoding: *
Accept-Encoding: compress;q=0.5,gzip;q=1.0
Accept-Encoding: gzip;q=1.0,identify;q=0.5,*;q=0

//响应实体
Content-Encoding: gzip

客户端可以给每种编码附带Q（质量）值参数来说明编码的优先级。Q值范围从 0.0 到 1.0，0.0 说明客户端不想接受所说明的编码，1.0 则表明最希望使用的编码。

identify 编码代号只能在 Accept-Encoding 首部中出现，客户端用它来说明相对于其他内容编码算法的优先级。

Content-Length

Content-Length 首部指示出报文中实体主体的字节大小。这个大小是包含了所有内容编码的，比如，对文本文件进行了 gzip 压缩的话，Content-Length 首部就是压缩后的大小，而不是原始大小。

除非使用了分块编码，否则 Content-Length 首部就是带有实体主体的报文必须使用的。使用 Content-Length 首部是为了能够检测出服务器奔溃而导致的报文截尾，并对共享持久连接的多个报文进行正确分段。

//请求和响应实体中字段相同
Content-Length: 567

Content-Cache
Expires
Last-Modified
ETag

Content-Range

HTTP 允许客户端实际上只请求文档的一部分，或者说某个范围。Range 首部在流行的点对点文件共享客户端软件中得到广泛应用，它们从不同的对等实体同时下载多媒体的不同部分。

请求主体

• Range

响应主体

• Accept-ranges
• Content-range

//请求报文
GET /bigfile.html HTTP/1.1
[...]

//响应报文
HTTP/1.1 200 OK
Content-type: text/html
Content-length: 65537
Accept-ranges: bytes

//范围请求报文
GET /bightml.html HTTP/1.1
Range: bytes=10224-20224
[...]

//范围响应报文
HTTP/1.1 206 partial
Content-Range: bytes=10224-20224
Accept-ranges: bytes

Content-MD5

尽管 HTTP 通常都是在像 TCP/IP 这样的可靠传输协议之上实现的，但仍有很多因素导致报文的一部分在传输过程中被修改，比如不兼容的转码代理，或者中间代理有误，等等。为检测实体主体的数据是否被不经意（或不希望有）地修改，发送方可以在生成初始的主体时，生成一个数据的校验和，这样接收方就可以通过检查这个校验和来捕获所有意外的实体修改了。

除了检查报文的完整性之外，MD5还可以当作散列表的关键字，用来快速定位文档并消除不必要的重复内容存储。除了这些可能的用法，一般不常用到 Content-MD5 首部。

传输编码

使用传输编码是为了改变报文中的数据在网络上的传输方式。最新的 HTTP 规范只定义了一种传输编码，就是分块编码。

当使用持久连接时，在服务器写主体之前，必须知道它的大小并在 Content-Length 首部中发送。如果服务器动态创建内容，就可能在发送之前无法知道主体的长度。

分块编码为这种困难提供了解决方案，只要允许服务器把主体逐块发送，说明每块的大小就可以了。因为主体是动态创建的，服务器可以缓冲它的一部分，发送其大小和相应的块，然后在主体发送完之前重复这个过程。服务器可以用大小为 0 的块作为主体结束的信号，这样就可以继续保持连接，为下一个响应做准备。

HTTP 协议中只定义了两种两个首部来描述和控制传输编码。

• TE: 用在请求首部中，告知服务器可以使用哪些传输编码扩展。可以用Q值来说明传输编码的优先顺序。
• Transfer-Encoding: 告知接收方为了可靠地传输报文，已经对其进行了何种编码。

下面的例子中，请求使用了 TE 首部来告诉服务器它可以接受分块编码（如果这是 HTTP/1.1 应用程序的话，这就是必须的）并且愿意接受附在分块编码的报文结尾上的拖挂：

GET /new_products.html HTTP/1.1
Host: www.joes-hardware.com
User-Agent: Mozila/4.61 [en] (WinNT; I)
TE: trailers,chunked
Trailer: Content-MD5

如果客户端的 TE 首部中说明它可以接受拖挂的话，就可以在分块的报文最后加上拖挂。产生原始响应的服务器也可以在分块的报文最后加上拖挂。拖挂内容是可选的元数据，客户端不一定需要理解和使用（客户端可以忽略并丢弃拖挂中的内容）。

拖挂中可以包含附带的首部字段，它们的值在报文开始的时候可能是无法确定的（例如，必须要先生成主体的内容）。Content-MD5 首部就是一个可以在拖挂中发送的首部，因为在文档生成之前，很难算出它的 MD5。

除了 Transfer-Encoding、Trailer以及 Content-Length 首部之外，其他 HTTP 首部都可以作为拖挂发送。

HTTP/1.1 200 OK
Content-type: text/plain
Transfer-encoding: chunked
Trailer: Content-MD5

//第一块数据块
27
we hold these truths to be sele-evident
//第二块数据块
28
we hold these truths to be sele-evident
//最后一块数据块
0
//拖挂
Content-MD5: ...