图解HTTP（六）HTTP首部
一、HTTP报文的结构：
二、4种首部字段：
1. 通用首部字段
请求报文和响应报文都会使用的首部。
|
首部字段名 |
说明 |
|---|---|
|
Cache-Control |
控制缓存行为 |
|
Connection |
逐跳首部、连接的管理 |
|
Date |
创建报文的日期时间 |
|
Pragma |
报文指令 |
|
Trailer |
报文末端的首部一览 |
|
Transfer-Encoding |
指定报文主体的传输编码方式 |
|
Upgrade |
升级为其他协议 |
|
Via |
代理服务器的相关信息 |
|
Warning |
错误通知 |
1.1 Cache-Control
通过指定首部字段Cache-Control的指令，就能操作缓存的工作机制。指令的参数是可选的，多个指令之间通过，分隔。
可用的指令按请求和响应分类如下：
缓存请求指令
| 指令 | 参数 | 说明 |
| no-cache | 无 | 强制向源服务器再次验证 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| max-age=[秒] | 必需 | 响应的最大Age值 |
| max-stale(=[秒]) | 可省略 | 接收已过期的响应 |
| min-fresh=[秒] | 必需 | 期望在指定时间内的响应仍有效 |
| no-transform | 无 | 代理不可更改媒体类型 |
| only-if-cached | 无 | 从缓存获取资源 |
| cache-extension | - | 新指令标记(token) |
缓存响应指令
| 指令 | 参数 | 说明 |
| public | 无 | 可向任意方向提供响应的缓存 |
| private | 可省略 | 仅向特定用户返回响应 |
| no-cache | 可省略 | 缓存前必须先确认其有效性 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| no-transform | 无 | 代理不可更改媒体类型 |
| must-revalidate | 无 | 可缓存但必须再向源服务器确认 |
| proxy-revalidate | 无 | 要求中间缓存服务器对缓存的响应有效性在进行确认 |
| max-age=[秒] | 必需 | 响应的最大Age值 |
| s-maxage=[秒] | 必需 | 公共缓存服务器响应的最大Age值 |
| cache-extension | - | 新指令标记(token) |
1.2 Connection
有如下两个作用：
- 控制不再转发给代理的首部字段
Connection:不再转发的首部字段名
- 管理持久连接: 1.1版本默认的是持久连接，当服务器想明确断开连接时，这指定connection 为close。1.1之前的版本默认的是非持久连接，若要维持持续连接，则指定为Keep-Alive.
Connection: close
Connection: Keep-Alive
1.3 Date
表明创建HTTP报文的日期和时间。
HTTP/1.1协议使用在RFC1123中规定的日期时间的格式，如下：
Date： Tue， 03 Jul 2016 05:12:30 GMT
之前版本使用在RFC850中定义的格式，如下：
Date： Tue， 03-Jul-16 05:12:30 GMT
此外，还有一种格式，它与C标准库内的asctime()函数的输出格式一致，如下：
Date： Tue， 03 Jul 05:12:30 2016
1.4 Pragma
Pragma是HTTP/1.1之前版本的历史遗留字段，仅作为与HTTP/1.0的向后兼容而定义。规范定义的形式唯一，如下所示：
Pragma: no-cache
该首部字段属于通用首部字段，但是只用在客户端发送的请求中。客户端会要求所有的中间服务器不返回缓存的资源。
若所有的中间服务器都能以HTTP/1.1为基准，那直接采用Cache-Control：no-cache指定缓存的处理方式最为理想。但要整体掌握全部中间服务器使用的HTTP协议版本却不现实。因此发送的请求会同时含有下面两个首部字段。
Cache-Control: no-cache
Pragma: no-cache
1.5 Trailer
该字段会事先说明在报文主题后记录了那些首部字段，可应用在HTTP/1.1版本分块传输编码时。
HTTP/1.1 200 OK Date： Tue， 03 Jul 2016 05:12:30 GMT Content-Type：text/html ... Tranfer-Encoding:chuncked #分块 Trailer：Expires ...(报文主体)... 0 Expires:Tue， 28 Sep 2016 05:12:30 GMT
以上用例中，指定首部字段Trailer的值为Expires,在报文主体之后出现了首部字段Expires.
1.6 Transfer-Encoding
规定了传输报文时采用的编码方式。HTTP/1.1的传输编码方式仅对分块传输编码有效。下例中,正如首部字段Transfer-Encoding中指定的那样,有效使用分块传输编码,且分别被分成3312字节和914字节大小的分块数据。
HTTP/1.1 200 OK Date： Tue， 03 Jul 2016 05:12:30 GMT Cache-Control：public, max-age=604800 Content-Type：text/javascript;charset=utf-8 Expires:Tue， 10 Jul 2016 05:12:30 GMT X-Frame-Options:DENY X-XSS-Protection:1;mode=block Content-Encoding:gzip Tranfer-Encoding:chuncked #分块 Connnection:keep-alive cf0 <--16进制(十进制为3312) ...3312字节分块数据... 392 <--16进制(十进制为914) ...914字节数据... 0
1.7 Upgrade
首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信,其参数值可以用来指定一个完全不同的通信协议。如下图,首部字段Upgrade指定的值为TLS/1.0。这里需要注意两个首部字段的对应关系,Connection的值被指定为Upgrade,而Upgrade首部字段产生的作用Upgrade对象仅限于客户端和邻接服务器之间。因此使用首部字段Upgrade时还需要额外指定Connection:Upgrade。对于富有首部字段Upgrade的请求,服务器可用101 SwitchingProtocols状态码来作为响应返回。
1.8 Via
使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径。报文经过代理或网关时,会先在首部字段Via中附加该服务器的信息,然后在进行传输。
首部字段Via不仅用于追踪报文的转发,还可以避免请求回环的发生。所以必须经过代理时附加该首部字段内容。如图,在经过代理服务器A时,Via首部信息附加了"1.0 gw.hackr.jp(squid/3.1)"这样的字符串值。行头的1.0是指接收请求的服务器上应用的HTTP协议版本。接下来经过代理服务器B时亦是如此,在Via首部附加服务器信息,也可增加一个新的Via首部写入服务器信息。Via首部是为了追踪传输路径,所以经常会和TRACE方法一起使用。比如代理服务器接收到由Trace方法发送过来的请求(其中Max-Forwards:0)时,代理服务器就不能再转发该请求了。这种情况下,代理服务器将自身的信息附加到Via首部后。返回该请求的响应。
1.9 Warning
在HTTP/1.1的Warning首部是从HTTP/1.0的响应首部(Retry-After)演变过来的,该首部通常会告知用户一些与缓存相关的问题的告警。Warning的首部格式如下(最后的日期时间可省略)：
warning： [警告码] [警告的主机:端口号] "[警告内容]" ([日期时间]) 小例子： Warning： 113 gw.hackr.jp:8080 "Heuristic wxpiration" Tue,03 Jul 2016 05:03:11 GMT
在HTTP/1.1中定义了7种告警。警告码对应的警告内容仅推荐参考。另外警告码具备扩展性。今后有可能追加新的警告码。
| 警告码 | 警告内容 | 解释说明 |
| 110 | Response stale(响应已过期) | 代理返回已过期的资源 |
| 111 | Revalidation failed(再验证失败) | 代理再验证资源有效性时失败(服务器无法到达等原因) |
| 112 | Disconnection operation(断开连接操作) | 代理与互联网连接被故意切断 |
| 113 | Herurstic expiration(试探性过期) | 响应的使用期超过24小时(有效缓存的设定时间大于24小时的情况下) |
| 199 | Miscellaneous warning(杂项警告) | 任意的警告内容 |
| 214 | Transformation applied(使用了转换) | 代理对内容编码或媒体类型等执行了某些处理时 |
| 299 | Miscellaneous persistent warning(持久杂项警告) | 任意的警告内容 |
2. 请求首部字段
从客户端向服务器发送请求时使用的首部，补充请求的附加内容、客户端信息、响应内容相关优先级等信息。
| 首部字段名 | 说明 |
|---|---|
| Accept | 用户代理可处理的媒体类型 |
| Accept-Charset | 优先的字符集 |
| Accept-Encoding | 优先的内容编码 |
| Accept-Language | 优先的语言 |
| Authorization | Web认证信息 |
| Expect | 期待服务器的行为 |
| From | 用户的电子邮箱地址 |
| Host | 请求资源所在服务器 |
| If-Match | 比较实体标记（ETag） |
| If-Modified-Since | 比较资源的更新时间 |
| If-Node-Match | 比较实体标记（与If-Match相反） |
| If-Range | 资源未更新时发送实体Byte的范围请求 |
| If-Unmodified-Since | 比较资源的更新时间（与If-Modified-Since相反） |
| Max-Forwards | 最大传输逐跳数 |
| Proxy-Authorization | 代理服务器要求客户端的认证信息 |
| Range | 实体的字节范围请求 |
| Referer | 对请求中URI的原始获取方 |
| TE | 传输编码的优先级 |
| User-Agent | HTTP客户端程序的信息 |
3. 响应首部字段
从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
| 首部字段名 | 说明 |
|---|---|
| Accept-Ranges | 是否接受字节范围请求 |
| Age | 推算资源创建经过时间 |
| ETag | 资源的匹配信息 |
| Location | 令客户端重定向至指定URI |
| Proxy-Authenticate | 代理服务器对客户端的认证信息 |
| Retry-After | 对再次发起请求的时机要求 |
| Server | HTTP服务器的安装信息 |
| Vary | 代理服务器缓存的管理信息 |
| WWW-Authenticate | 服务器对客户端的认证信息 |
4. 实体首部字段
针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。
| 首部字段名 | 说明 |
|---|---|
| Allow | 资源可支持的HTTP方法 |
| Content-Encoding | 实体主体适用的编码方式 |
| Content-Language | 实体主体的自然语言 |
| Content-Length | 实体主体的大小（字节） |
| Content-Location | 替代对应资源的URI |
| Content-MD5 | 实体主体的报文摘要 |
| Content-Range | 实体主体的位置范围 |
| Content-Type | 实体主体的媒体类型 |
| Expires | 实体主体过期的日期时间 |
| Last-Modified | 资源的最后修改日期时间 |
