概述

HTTP协议的请求和响应报文中必定包含HTTP首部，只是我们平时在使用Web的过程中感受不到它。

HTTP报文首部

HTTP协议的请求和响应报文中必定包含HTTP首部。首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。对于客户端用户来说，这些信息中的大部分内容都无须亲自查看。
报文首部由几个字段构成。

HTTP请求报文

在请求中，HTTP报文由方法、URI、HTTP版本、HTTP首部字段等部分构成。

HTTP响应报文

在响应中，HTTP报文由HTTP版本、状态码（数字和原因短语）、HTTP首部字段3部分构成。

在报文众多的字段当中，HTTP首部字段包含的信息最为丰富。
首部字段同时存在于请求和响应报文内，并涵盖HTTP报文相关的内容信息。
因HTTP版本或扩展规范的变化，首部字段可支持的字段内容略有不同。

HTTP首部字段

HTTP首部字段传递重要信息

HTTP首部字段是构成HTTP报文的要素之一。在客户端与服务器之间以HTTP协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。
使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

HTTP首部字段结构

HTTP首部字段是由首部字段名和字段值构成的，中间用冒号“:”分隔。

首部字段名: 字段值

例如，在HTTP首部中以Content-Type这个字段来表示报文主体的对象类型。

Content-Type：text/html
``
另外，字段值对应单个HTTP首部字段可以有多个值，如下所示。
```xml
Keep-Alive：timeout=5, max=100

若HTTP首部字段重复了会如何
当HTTP报文首部中出现了两个或两个以上具有相同首部字段名时会怎么样？这种情况在规范内尚未明确，根据浏览器内部处理逻辑的不同，结果可能并不一致。有效浏览器会优先处理第一次出现的首部字段，而有些则会优先处理最后出现的首部字段。

4种HTTP首部字段类型

通用首部字段（General Header Fields）

请求报文和响应报文两方都会使用的首部。

请求首部字段（Request Header Fields）

从客户端向服务端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。

响应首部字段（Response Header Fields）

从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。

实体首部字段（Entity Header Fields）

针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

HTTP/1.1首部字段一览

HTTP/1.1规范定义了如下47种首部字段

通用首部字段

请求首部字段

响应首部字段

实体首部字段

非HTTP/1.1首部字段

在HTTP协议通信交互中使用到的首部字段、不限于RFC2616中定义的47中首部字段。还有Cookie、Set-Cookie和Content-Disposition等在其他RFC中定义的首部字段，它们的使用频率也很高。
这些非正式的首部字段统一归纳在RFC4229 HTTP Header Field Registrations中。

End-to-end首部和Hop-by-hop首部

HTTP首部字段将定义成缓存代理和非缓存代理的行为，分成2种类型。
端到端首部（End-to-end Header）
分在此类别中的首部会转发给请求/响应对应的最终接收目标，且必须保持在由缓存生成的响应中，另外规定它必须被转发。
逐跳首部（Hop-by-hop Header）
分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再转发。HTTP/1.1和之后版本中，如果要使用Hop-by-hop首部，需要提供Connction首部字段。
下面列举了HTTP/1.1中的逐跳首部字段。除这8个逐跳首部字段之外，其他所有字段都属于端到端首部。

1. Connection
2. Keep-Alive
3. Proxy-Authenticate
4. Proxy-Authorization
5. Trailer
6. TE
7. Transfer-Encoding
8. Upgrade

HTTP/1.1通用首部字段

通用首部字段是指，请求报文和响应报文双方都会使用的首部。

Cache-Control

通过指定首部字段Cache-Control的指令，就能操作缓存的工作机制。

指令的参数是可选的，多个指令之间通过“，”分隔。首部字段Cache-Control的指令可用于请求及响应时。

Cache-Control：private, max-age=0, no-cache

Cache-Control指令一览

可用的指令按请求和响应分类如下所示。
缓存请求指令

缓存响应指令

表示是否能缓存的指令

public指令

Cache-Control: public

当指定使用public指令时，则明确表明其他用户也可利用缓存。

private 指令

Cache-Control: private

当指定private指令后，响应只以特定的用户作为对象，这与public指定的行为相反。
缓存服务器会对该特定用户提供资源缓存的服务，对于其他用户发送过来的请求，代理服务器则不会返回缓存。

no-cache指令

Cache-Control：no-cache

使用no-cache指令的目的是为了防止从缓存中返回过期的资源。
客户端发送的请求如果包含no-cache指令，则表示客户端将不会接收缓存过的响应。于是，“中间”的缓存服务器必须把客户端请求转发给源服务器。
如果服务器返回的响应中包含no-cache指令，那么缓存服务器不能对资源进行缓存。源服务器以后也将不再对缓存服务器请求中提出的资源有效性进行确认，且禁止其对响应资源进行缓存操作。

Cache-Control: no-cache=Location

由服务器返回的响应中，若报文首部字段Cache-Control对no-cache字段名具体指定参数值，那么客户端在接收到这个被指定参数值的首部字段对应的响应报文后，就不再使用缓存。换言之，无参数值的首部字段可以使用缓存。只能在响应指令中指定该参数。

控制可执行缓存的对象的指令

no-store指令

Cache-Control：no-store

当使用no-store指令时，暗示请求（和对应的响应）或响应中包含机密信息。
因此，该指令规定缓存不能在本地存储请求或响应的任一部分。

指定缓存期限和认证的指令

s-maxage指令

Cache-Control：s-maxage=604800（单位：秒）

s-maxage指令的功能和max-age指令的相同，它们的不同点是s-maxage指令只适用于供多位用户适用的公共缓存服务器。也就是说对于向同一用户重复返回响应的服务器来说，这个指令没有任何作用。
另外，当使用s-maxage指令后，则直接忽略对Expires首部字段及max-age指令的处理。

max-age指令

Cache-Control：max-age=604800（单位：秒）

当客户端发送的请求中包含max-age指令时，如果判定缓存的缓存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。另外，当指定max-age值为0，那么缓存服务器通常需要将请求转发给源服务器。
当服务器返回的响应中包含max-age指令时，缓存服务器将不对资源的有效性再做确认，而max-age数值代表资源保存为缓存的最长时间。
应用HTTP/1.1版本的缓存服务器遇到同时存在Expires首部字段的情况时，会优先处理max-age指令，而忽略掉Expires首部字段。而HTTP/1.0版本的缓存服务器的情况却相反，max-age指令会被忽略掉。

min-fresh指令

Cache-Control：min-fresh=60（单位：秒）

min-fresh指令要求缓存服务器返回至少还未过指定时间的缓存资源。
比如，当指定min-fresh为60秒后，在这60秒以内如果有超过有效期限的资源都无法作为响应返回了。

max-stale指令

Cache-Control: max-stale=3600（单位：秒）

使用max-stale可指示缓存资源，即使过期也照常接收。
如果指令未指定参数值，无论经过多久，客户端都会接收响应；如果指令中指定了具体数值，那么即使过期，只有仍处于max-stale指定的时间内，仍旧会被客户端接收。

only-if-cached指令

Cache-Control: only-if-cached

使用only-if-cached指令表示客户端仅在缓存服务器本地缓存目标资源的情况下才会要求其返回。换言之，该指令要求缓存服务器不重新加载响应，也不会再次确认资源有效性。若发生请求缓存服务器的本地缓存无响应，则返回状态码504 Gateway Timeout。

must-revalidate指令

Cache-Control：must-revalidate

使用must-revalidate指令，代理会向源服务器再次验证即将返回的响应缓存目前是否仍然有效。
若代理无法连通源服务器再次获取有效资源的话，缓存必须给客户端一条504（Gateway Timeout）状态码。
另外，使用must-revalidate指令会忽略请求的max-stale指令（即使已经在首部使用了max-stale，也不会再有效果）。

proxy-revalidate指令

Cache-Control：proxy-revalidate

proxy-revalidate指令要求所以的缓存服务器在接收到客户端带有该指令的请求返回响应之前，必须再次验证缓存的有效性。

no-transform指令

Cache-Control：no-transform

使用no-transform指令规定无论是在请求还是响应中，缓存都不能改变实体主体的媒体类型。
这样做可防止缓存或代理压缩图片等类似操作。

Cache-Control扩展

cache-extension token

Cache-Control: private,community="UCI"

通过cache-extension标记（token），可以扩展Cache-Control首部字段内的指令。
如上例，Cache-Control首部字段本身没有community这个指令。借助extension tokens实现了该指令的添加。如果缓存服务器不能理解community这个新指令，就会直接忽略。因此，extension tokens仅对能理解它的缓存服务器来说是有意义的。

Connection

Connection首部字段具备如下两个作用。

• 控制不再转发给代理的首部字段。
• 管理持久连接。

控制代理不再转发的首部字段

Connection：不再转发的首部字段名称。

在客户端发送请求和服务器返回响应内，使用Connection首部字段，可控制代理不再转发的首部字段（即Hop-by-hop首部）。

管理持久连接

Connection：close

HTTP/1.1版本的默认连接都是持久连接。为此，客户端会在持久连接上联系发送请求。当服务器端想明确断开连接时，则指定Connection首部字段的值为 Close。
HTTP1.1 之前默认都是非持久化连接.。持久连接需要加上== Keep-Alive==

HTTP/1.1之前的HTTP版本的默认连接都是非持久连接。为此，如果想在旧版本的HTTP协议上维持持续连接，则需要指定Connection首部字段的值为Keep-Alive。
如上图1说是，客户端发送请求服务器时，服务器端会像上图2那样加上首部字段Keep-Alive及首部字段Connection后返回响应。

Date

首部字段Date表明创建HTTP报文的日期和时间。

HTTP/1.1协议使用在RFC1123中规定的日期时间的格式，如下：

之前的HTTP协议版本中使用在RFC850中定义的格式，如下：

除此之外，还有一种格式。它与C标准库的asctime()函数的输出格式一致。

Pragma

Pragma是HTTP/1.1之前版本的历史遗留字段，仅作为与HTTP/1.0的向后兼容而定义。
规范定义的形式唯一，如下所示。

Pragma: no-cache

该首部字段属于通用首部字段，但只用在客户端发送的请求中。客户端会要求所有的中间服务器不返回缓存的资源。

所有的中间服务器如果都能够以HTTP/1.1为基准，那直接采用Cache-Control:no-cache指定缓存的处理方式是最为理想的。但要整体掌握全部中间服务器使用的HTTP协议版本却是不现实的。因此，发送的请求会同时含有下面两个首部字段。

Cache-Conctrol: no-cache
Pragma: no-cache

Trailer

首部字段Trailer会事先说明在报文主体后记录了哪些首部字段。该首部字段可应用在HTTP/1.1版本分块传输编码时。

以上用例中，指定首部字段Trailer的值为Expires，在报文主体之后（分块长度0之后）出现了首部字段Expires。

Transfer-Encoding

首部字段Transfer-Encoding规定了传输报文主体时采用的编码方式。
HTTP/1.1的传输编码方式仅对分块传输编码有效。

以上用例中，正如在首部字段Transfer-Encoding中指定的那样，有效使用分块传输编码，且分别分成3312字节和914字节大小的分块数据。

Upgrade

首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。

上图用例中，首部字段Upgrade指定的值为TLS/1.0。请注意此处两个字段首部字段的对应关系，Connection的值被指定为Upgrade。Upgrade首部字段产生作用的Upgrade对象仅限于客户端和邻接服务器之间。因此，使用首部字段Upgrade时，还需要额外指定Connection:Upgrade。
对于附有首部字段Upgrade的请求，服务器可用101 Swiching Protocols状态码作为响应返回。

Via

使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径。
报文经过代理或网关时，会首先在首部字段Via中附加该服务器的信息，然后再进行转发。这个做法和traceroute及电子邮件的Recived首部的工作机制很类似。
首部字段Via不仅用于追踪报文的转发，还可避免请求回环的发生。所以必须在经过代理时附加该首部字段内容。

上图用例中，在经过代理服务器A时，Via首部附加了“1.0 gw.hackr.jp(Squid/3.1)”这样的字符串值。行头的1.0是指接收请求的服务器上应用的HTTP协议版本。接下来经过代理服务器B亦是如此，在Via首部附加服务器信息，也可增加1个新的Via首部写入服务器信息。
Via首部是为了追踪传输路径，所以经常会和Trace方法一起使用。比如，代理服务器接收到由Trace方法发送过来的请求（其中Max-Forwards:0）时，代理服务器就不能再转发该请求了。这种情况下，代理服务器会将自身信息附加到Via首部后，返回该请求的响应。

Warning

HTTP/1.1的Warning首部是从HTTP/1.0的响应首部（Retry-After）演变过来的。该首部通常会告知用户一些与缓存相关的问题警告。
格式如下：

HTTP/1.1 警告码

请求首部字段

请求首部字段是从客户端往服务器端发送请求报文中所使用的字段，用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。

Accept

Accept首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。可使用type/subtype这种格式，一次指定多种媒体类型。
下面试举几个媒体类型的例子。

• 文本文件
  text/html，text/plain，text/css …
  application/xhtml+xml，application/xml …
• 图片文件
  image/jpeg，image/gif，image/png …
• 视频文件
  video/mpeg，video/quicktime …
• 应用程序使用的二进制文件
  application/octet-stream，application/zip …
  比如，如果浏览器不支持PNG图片的显示，那么Accept就不指定image/png，而指定可处理的image/gif和image/jpeg等图片类型。
  若想要给显示的媒体类型增加优先级，则使用q=来额外表示权重值，用分号（；）进行分隔。权重值q的范围是0~1（可精确到小数点后3位），且1为最大。不指定权重q值时，默认权重为q=1.0.
  当服务器提供多种内容时，将会首先返回权重值最高的媒体类型。

Accept-Charset

Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外，可一次性指定多种字符集。与首部字段 Accept 相同的是可用权重 q 值来表示相对优先级。该首部字段应用于内容协商机制的服务器驱动协商。

Accept-Encoding

Accept-Encoding首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级。可一次性指定多种内容编码。
下面试举几个内容编码的例子：

• gzip
  由文件压缩程序gzip（GNU zip）生成的编码格式（RFC1952）,采用Lempel-Ziv算法（LZ77）及32位循环冗余校验（Cyclic Redundancy Check，通常CRC）。
• compress
  由UNIX文件压缩程序compress生成的编码格式，采用Lempel-Ziv-Welch算法（LZW）。
• deflate
  组合使用zlib格式（RFC1950）及由deflate压缩算法（RFC1951）生成的编码格式。
• identity
  不执行压缩或不会变化的默认编码格式。
  采用权重q值来表示相对优先级，这点与首部字段Accpet相同，另外，也可使用星号（*）作为通配符，指定任意编码格式。

Accept-Language

首部字段Accept-Language用来告知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级。可一次指定多种自然语言集。
和Accept首部字段一样，权重值q来表示相对优先级。在上述图例中，客户端在服务器有中文版资源的情况下，会请求其返回中文版对应的响应，没有中文版时，则请求返回英文版响应。

Authorization

首部字段Authorization是用来告知服务器，用户代理的认证信息（证书值）。通常，想要通过服务器认证的用户代理会在接收到返回的401状态码响应后，把首部字段Authorization加入请求中。共用缓存在接收到含有Authorization首部字段的请求时的操作处理会略有差异。

Expect

客户端使用首部字段Expect来告知服务器，期望出现的某种特定行为。如果服务器无法理解客户端的期望做出回应而发送错误时，会返回状态码 417 Expectation Failed。
客户端可以利用该首部字段，写明所期望的扩展。虽然HTTP/1.1规范只定义了100-continue（状态码 100 Continue之意）。
等待状态码100响应的客户端在发生请求时，需要指定Expect 100-continue。

From

用来告知服务器使用用户代理的用户的电子邮件地址。

Host

首部字段Host会告知服务器，请求的资源所处的互联网主机名称和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段。
首部字段Host和以单台服务器分配多个域名的虚拟主机的工作机制有很密切的关联，这是首部字段Host必须存在的意义。
请求被发送至服务器时，请求中的主机名会用IP地址直接替换解决。但如果这时，相同的IP地址下部署运行多个域名，那么服务器就会无法理解究竟是哪个域名对应的请求。因此，就需要使用首部字段Host来明确指出请求的主机名。若服务器未设定主机名，那直接发送一个空值即可。如下所示：
Host：

if-Match

形如If-xxx这种样式的请求首部字段，都可称为条件请求。服务器接收到附带条件请求后，只有判断指定条件为真时，才会执行请求。

只有当If-Match的字段值跟ETag值匹配一致时，服务器才会接受请求。
首部字段If-Match，属附带条件之一，它会告知服务器匹配资源所用的实体标记（ETag）值。这时的服务器无法使用弱ETag值。
服务器会比对If-Match的字段值和资源的ETag值，仅当两者一致时，才会执行请求。反之，则返回状态码412 Precodition Failed的响应。
还可以使用星号（*）指定If-Match的字段值。针对这种情况，服务器将会忽略ETag的值，只要资源存在就处理请求。

If-Modified-Since

首部字段If-Modified-Since，属附带条件之一，它会告知服务器If-Modified-Since字段值早于资源的更新时间，则希望能处理该请求。而在指定If-Modified-Since字段值的日期时间之后，如果请求的资源都没有过更新，则返回状态码304 Not Modified的响应。
If-Modified-Since用于确认代理或客户端拥有的本地资源的有效性。获取资源的更新日期时间，可通过确认首部字段Last-Modified来确定。

If-None-Match

首部字段If-None-Match属于附带条件之一。它和首部字段If-Match作用相反。用于指定If-None-Match字段值的实体标记（ETag）值与请求资源的ETag不一致时，它就告知服务器处理该请求。
在GET或HEAD方法中使用首部字段If-None-Match可获取最新的资源。因此，这与使用首部字段If-Modified-Since时有些类似。

If-Range

首部字段If-Range属于附带条件之一。它告知服务器若指定的If-Range字段值（ETag或者时间）和请求资源的ETag值或时间相一致时，则作为范围请求处理。反之，则返回全体资源。

通过上述图例我们可以看出不使用首部字段If-Range发送请求的情况。服务器端的资源如果更新，那客户端持有资源中的一部分也会随之无效，当然，范围请求作为前提是无效的。这是，服务器会暂且以状态码412 Precodition Failed作为响应返回，其目的是催促客户端再次发送请求。这样一来，与使用首部字段If-Range比起来，就需要花费两倍的功夫。

If-Unmodified-Since

首部字段If-Unmodified-Since和首部字段If-Modified-Since的作用相反。它的作用是告知服务器，指定的请求资源只有在字段值内指定的日期时间之后，未发生更新的情况下，才能处理请求。如果在指定日期时间后发生了更新，则以状态码412 Precodition Failed作为响应返回。

Max-Forwards

Max-Forwards：10
通过Trace方法或Options方法，发送包含首部字段Max-Forwards的请求时，该字段以十进制整数形式指定可经过的服务器最大数目。服务器在往下一个服务器转发请求之前，会将Max-Forwards的值减1后重新赋值。当服务器接收到Max-Forwards值为0的请求时，则不再进行转发，而是直接返回响应。
使用HTTP协议通信时，请求可能会经过代理等多台服务器。途中，如果代理服务器由于某些原因导致请求转发失败，客户端也就等不到服务器返回的响应了。对此，我们无从可知。
可以灵活使用首部字段Max-Forwards，针对以上问题产生的原因展开调查。由于当Max-Forwards字段值为0时，服务器就会立即返回响应，由此我们至少可以对以那台服务器为终点的传输路径的通信状况有所把握。

Proxy-Authorization

Proxy-Authorization：Basic dGlwOjkpNLAGfFY5
接收到从代理服务器发来的认证质询时，客户端会发送包含首部字段Proxy-Authorization的请求，以告知服务器认证所需要的信息。
这个行为是与客户端和服务器之间的HTTP访问认证相类似的，不同之处在于，认证行为发生在客户端与代理之间。客户端与服务器之间的认证，使用首部字段Authorization可起到相同作用。有关HTTP访问认证，后面的章节会详尽阐述。

Range

Range：bytes=5001-10000
对于只需获取部分资源的范围请求，包含首部字段Range即可告知服务器资源的指定范围。上面的示例表示请求获取从第5001字节至第10000字节的资源。
接收到附带Range首部字段请求的服务器，会在处理请求之后返回状态码206 Partial Content的响应。无法处理该范围请求时，则会返回状态码200 OK的响应及全部资源。

Referer

首部字段Referer会告知服务器请求的原始资源的URL。
客户端一般都会发送Refer首部字段给服务器。但当直接在浏览器的地址栏输入URI，或出于安全性的考虑时，也可以不发生该首部字段。
因为原始资源的URI中的查询字符串可能含有ID和密码等保密信息，要是写进Referer转发给其他服务器，则有可能导致保密信息的泄漏。

TE

TE：gzip，deflate;q=0.5
首部字段TE会告知服务器客户端能够处理响应的传输编码方式及相对优先级。它和首部字段Accept-Encoding的功能很相像，但是用于传输编码。
首部字段TE除指定传输编码之外，还可以指定伴随trailer字段的分块传输编码的方式。应用后者时，只需把trailers赋值给该字段值。
TE：trailers

User-Agent

首部字段User-Agent会将创建请求的浏览器和用户代理名称等信息传达给服务器。
由网络爬虫发起请求时，有可能会在该字段内添加爬虫作者的电子邮件地址。此外，如果请求经过代理，那么中间也很可能被添加上代理服务器的名称。

响应首部字段

响应首部字段是由服务器端向客户端返回响应报文中所使用的字段，用于补充响应的附加信息、服务器信息，以及客户端的附加要求等信息。

Accept-Ranges

首部字段Accept-Ranges是用来告知客户端服务器是否能处理范围请求，以指定获取服务器端某个部分的资源。
可指定的字段值有两种，可处理范围请求时指定其为bytes，反之则指定其为none。

Age

首部字段Age能告知客户端，源服务器在多久前创建了响应。字段值的单位为秒。
若创建该响应的服务器是缓存服务器，Age值是指缓存后的响应再次发起认证到认证完成的时间值。代理创建响应时必须加上首部字段Age。

ETag

首部字段ETag能告知客户端实体标识。它是一种可将资源以字符串形式做唯一标识的方式。服务器会为每份资源分配对应的ETag值。
另外，当资源更新时，ETag值也需要更新。生成ETag值时，并没有统一的算法规则，而仅仅是由服务器来分配的。

资源被缓存时，就会被分配唯一性标识。例如，当使用中文版的浏览器访问 http://www.google.com/ 时，就会返回中文版对应的资源，而使用英文版的浏览器访问时，则会返回英文版对应的资源。两者的 URI 是相同的，所以仅凭 URI 指定缓存的资源是相当困难的。若在下载过程中出现连接中断、再连接的情况，都会依照ETag 值来指定资源。

强ETag和弱ETag值

强ETag值

强ETag值，不论发生多么细微的变化都会改变其值。
ETag：“usagi-1234”

弱ETag值

弱ETag值只用于提示资源是否相同。只有资源发送了根本改变，产生差异是才会改变ETag值。这是，会在字段值最开始处附加W/。
ETag：W/“usagi-1234”

Location

使用首部字段Location可以将响应接收方引导至某个与请求URI位置不同的资源。
基本上，该字段会配合3xx：Redirection的响应，提供重定向的URI。
几乎所有的浏览器在接收到包含首部字段Location的响应后，都会强制性地尝试对已提示的重定向资源的访问。

Proxy-Authenticate

Proxy-Authenticate：Basic realm=“Usagidesign Auth”
首部字段Proxy-Authenticate会把由代理服务器所要求的认证信息发送给客户端。
它与客户端和服务器之间的HTTP访问认证的行为相似，不同之处在于其认证行为是客户端与代理之间进行的。而客户端与服务器之间进行认证时，首部字段WWW-Authorization有着相同的作用。

Retry-After

首部字段Retry-After告知客户端应该在多久之后再次发送请求。主要配合状态码503 Service Unavailable响应，或3xx Redirect响应一起使用。
字段值可以指定为具体的日期时间（Wed, 04 Jul 2012 06： 34： 24 GMT 等格式），也可以是创建响应后的秒数。

Server

首部字段Server告知客户端当前服务器上安装的HTTP服务器应用程序的信息。不单单会标出服务器上的软件应用名称，还有可能包括版本号和安装时启用的可选项。

Vary

首部字段 Vary 可对缓存进行控制。源服务器会向代理服务器传达关于本地缓存使用方法的命令。从代理服务器接收到源服务器返回包含 Vary 指定项的响应之后，若再要进行缓存，仅对请求中含有相同Vary 指定首部字段的请求返回缓存。即使对相同资源发起请求，但由于 Vary 指定的首部字段不相同，因此必须要从源服务器重新获取资源。

WWW-Authenticate

WWW-Authenticate：Basic realm=“Usagidesign Auth”
首部字段WWW-Authenticate用于HTTP访问认证。它会告知客户端适用于访问请求URI所指定资源的认证方案（Basic或是Digest）和带参数提示的质询（challenge）。状态码401 Unauthorized响应中，肯定带有首部字段WWW-Authenticate。
上述示例中，realm字段的字符串是为了辨别请求URI指定资源所受到的保护策略。

实体首部字段

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等于实体相关的信息。

Allow

首部字段Allow用于通知客户端能够支持Request-URI指定资源的所有HTTP方法。当服务器接收到不支持的HTTP方法时，会以状态码405 Method Not Allowed作为响应返回。与此同时，还会把所有能支持的HTTP方法写入首部字段Allow后返回。

Content-Encoding

首部字段Content-Encoding会告知客户端，服务器对实体的主体部分选用的内容编码方式。内容编码是指在不丢失实体信息的前提下所进行的压缩。

主要采用以下4种内容编码的方式。(各种方式的说明参考Accept-Encoding首部字段）

• gzip
• compress
• deflate
• identity

Content-Language

首部字段Content-Language会告知客户端，实体主体使用的自然语言（指中文或英文等语言）。

Content-Length

首部字段Content-Length表明了实体主体部分的大小（单位是字节）。对实体主体进行内容编码传输时，不能再使用实体首部的Content-Length字段，由于实体主体大小的计算方法略微复杂，所以在此不再展开。

Content-Location

首部字段Content-Location给出与报文主体部分相对应的URL。和首部字段Location不同，Content-Location表示的是报文主体返回资源对应的URI。
比如，对于使用首部字段Accept-Language的服务器驱动型请求，当返回的页面内容与实际请求的对象不同时，首部字段Content-Location内会写明URI（访问http://www.hackr.jp/ 返回的对象却是http://www.hackr.jp/index-ja.html等类似情况）。

Content-MD5

首部字段Content-MD5是一串由MD5算法生成的值，其目的在于检查报文主体在传输过程中是否保持完整，以及确认传输到达。
对报文主体执行MD5算法获得的128位二进制数，再通过Base64编码后将结果写入Content-MD5字段值。由于HTTP首部无法记录二进制值，所以要通过Base64编码处理。为确保报文的有效性，作为接收方的客户端会对报文主体再执行一次相同的MD5算法，然后计算出的值与字段值做比较后，即可判断出报文主体的准确性。
采用这种方法，对内容上的偶发性改变是无从查证的，也无法检测出恶意篡改；其中一个原因是，内容如果能够被篡改，那么同时意味着Content-MD5也可重新计算然后被篡改。所以处在接收阶段的客户端是无法意识到报文主体以及首部字段Content-MD5是已经被篡改过的。

Content-Range

针对范围请求，返回响应时使用的首部字段Content-Range，能告知客户端作为响应返回的实体的哪个部分符合范围请求。字段值以字节为单位，表示当前发送部分及整个实体大小。

Content-Type

首部字段Content-Type说明了实体主体内对象的媒体类型。和首部字段Accept一样，字段值用type/subtype形式赋值。
参数charset使用iso-8859-1或euc-jp等字符集进行赋值。

Expires

首部字段Expires会将资源失效的日期告知客户端。缓存服务器在接收到含有首部字段Expires的响应后，当有请求来获取服务器数据时会以缓存来应答客户端，Expires字段值指定的时间之前，响应的副本会一直被保存。当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。
源服务器不希望缓存服务器对资源缓存时，最后在Expires字段内写入与首部字段Date相同的时间值。
但是，当首部字段Cache-Control有指定max-age指令时，比起首部字段Expires，会优先处理max-age指令。

Last-Modified

首部字段Last-Modifed指明资源最终修改的时间。一般来说，这个值就是Request-URI指定资源被修改的时间。但类似使用CGI脚本进行动态数据处理时，该值有可能会变成数据最终修改时的时间。

参考

图解HTTP六：HTTP 首部
【图解HTTP读书笔记】第六章：HTTP首部