目录
请求首部字段
请求首部字段是从客户端往服务器端发送请求报文中所使用的字段， 用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等 内容。
Accept
Accept首部字段可通知服务器，用户代理能够处理的媒体类型及媒体 类型的相对优先级。可使用type/ subtype这种形式，一次指定多种媒 体类型。
下面我们试举几个媒体类型的例子。
文本文件
text/html, text/plain, text/ css…
application/xhtrnl+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=来额外表示权重值 1'用分号（；）进行分隔。权重值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生成的编码格式，采用LempelZi\T-Welch算法(L'ZW)。
deflate
组合使用zlib格式(RfC1950)及由deflate压缩算法 (RfC1951)生成的编码格式。
identity
不执行压缩或不会变化的默认编码格式
采用权重q值来表示相对优先级，这点与首部字段Accept相同。另 外，也可使用星号（＊）作为通配符，指定任意的编码格式。
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
首部字段From用来告知服务器使用用户代理的用户的电子邮件地址。通常，其使用目的就是为了显示搜索引擎等用户代理的负责人的 电子邮件联系方式。使用代理时，应尽可能包含From首部字段（但 可能会因代理不同，将电子邮件地址记录在User-Agent首部字段内）。
Host
首部字段Host会告知服务器，请求的资源所处的互联网主机名和端 口号。Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请 求内的首部字段。
首部字段Host和以单台服务器分配多个域名的虚拟主机的工作机制 有很密切的关联，这是首部字段Host必须存在的意义。
请求被发送至服务器时，请求中的主机名会用IP地址直接替换解 决。但如果这时，相同的IP地址下部署运行着多个域名，那么服务 器就会无法理解究竟是哪个域名对应的请求。因此，就需要使用首部 字段Host来明确指出请求的主机名。若服务器未设定主机名，那直 接发送一个空值即可。如下所示。
If-Match
形如If-xxx这种样式的请求首部字段，都可称为条件请求。服务器接 收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。
首部字段If-Match, 属附带条件之一，它会告知服务器匹配资源所用 的实体标记(ETag)值。这时的服务器无法使用弱ETag值。
服务器会比对If-Match的字段值和资源的ETag值，仅当两者一致时，才会执行请求。反之，则返回状态码412 Precondition Failed的响 应。
还可以使用星号（＊）指定If-Match的字段值。针对这种情况，服务 器将会忽略ETag的值，只要资源存在就处理请求。
If-Moclified-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 Precondition Failed作为响应返回，其目的是催促客户端再次发送请 求。这样一来，与使用首部字段If-Range比起来，就需要花费两倍的 功夫。
If-Unmodified-Since
首部字段If- Unmodified-Since和首部字段If-Modified-Since的作用相 反。它的作用的是告知服务器，指定的请求资源只有在字段值内指定 的日期时间之后，未发生更新的情况下，才能处理请求。如果在指定 日期时间后发生了更新，则以状态码412 Precondition Failed作为响应 返回。
Max-Forwards
通过TRACE方法或OPTIONS方法，发送包含首部字段Max-Forwards的请求时，该字段以十进制整数形式指定可经过的服务器最 大数目。服务器在往下一个服务器转发请求之前，Max-Forwards的 值减1后重新赋值。当服务器接收到Max-Forwards值为0的请求时，则不再进行转发，而是直接返回响应。
使用HTTP协议通信时，请求可能会经过代理等多台服务器。途中， 如果代理服务器由于某些原因导致请求转发失败，客户端也就等不到 服务器返回的响应了。对此，我们无从可知。
可以灵活使用首部字段Max-Forwards, 针对以上问题产生的原因展 开调查。由于当Max-Forwards字段值为0时，服务器就会立即返回 响应，由此我们至少可以对以那台服务器为终点的传输路径的通信状 况有所把握。
Proxy-Authorization
接收到从代理服务器发来的认证质询时，客户端会发送包含首部字段 Proxy-Authorization的请求，以告知服务器认证所需要的信息。
这个行为是与客户端和服务器之间的HTTP访问认证相类似的，不同 之处在于，认证行为发生在客户端与代理之间。客户端与服务器之间 的认证，使用首部字段Authorization可起到相同作用。有关HTTP访 问认证，后面的章节会作详尽阐述。
Range
对于只需获取部分资源的范围请求，包含首部字段Range即可告知服 务器资源的指定范围。上面的示例表示请求获取从第5001字节至第10000字节的资源。
接收到附带Range首部字段请求的服务器，会在处理请求之后返回状 态码为206 Partial Content的响应。无法处理该范围请求时，则会返 回状态码200 OK的响应及全部资源。
Referer
首部字段Referer会告知服务器请求的原始资源的URI。
客户端一般都会发送Referer首部字段给服务器。但当直接在浏览器 的地址栏输入URI, 或出于安全性的考虑时，也可以不发送该首部字 段。
因为原始资源的URI中的查询字符串可能含有ID和密码等保密信 息，要是写进Referer转发给其他服务器，则有可能导致保密信息的 泄露。
另外，Referer的正确的拼写应该是Referrer, 但不知为何，大家一直 沿用这个错误的拼写。
TE
首部字段TE会告知服务器客户端能够处理响应的传输编码方式及相 对优先级。它和首部字段Accept- Encoding的功能很相像，但是用于 传输编码。
首部字段TE除指定传输编码之外，还可以指定伴随trailer字段的分 块传输编码的方式。应用后者时，只需把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值来指定资 源。
Location
使用首部字段Location可以将响应接收方引导至某个与请求URI位置 不同的资源。
基本上，该字段会配合3xx : Redirection的响应，提供重定向的 URI。
几乎所有的浏览器在接收到包含首部字段Location的响应后，都会强 制性地尝试对已提示的重定向资源的访问。
Proxy-Authenticate
首部字段Proxy-Authenticate会把由代理服务器所要求的认证信息发送 给客户端。
它与客户端和服务器之间的HTTP访问认证的行为相似，不同之处在 于其认证行为是在客户端与代理之间进行的。而客户端与服务器之间 进行认证时，首部字段WWW-Authorization有着相同的作用。
Retry-After
首部字段Retry-After告知客户端应该在多久之后再次发送请求。主要 配合状态码503 Service Unavailable响应，或3 xx Redirect响应一起使 用。
字段值可以指定为具体的日期时间(Wed, 04 Jul 2012 06: 34: 24 GMT等格式），也可以是创建响应后的秒数。
Server
首部字段Server告知客户端当前服务器上安装的HTTP服务器应用程 序的信息。不单单会标出服务器上的软件应用名称，还有可能包括版 本号和安装时启用的可选项。
Vary
首部字段Vary可对缓存进行控制。源服务器会向代理服务器传达关 于本地缓存使用方法的命令。
从代理服务器接收到源服务器返回包含Vary指定项的响应之后，若 再要进行缓存，仅对请求中含有相同Vary指定首部字段的请求返回 缓存。即使对相同资源发起请求，但由于Vary指定的首部字段不相 同，因此必须要从源服务器重新获取资源。
WWW-Authenticate
首部字段WWW-Authenticate用于HTTP访问认证。它会告知客户端 适用于访问请求URI所指定资源的认证方案(Basic或是Digest)和 带参数提示的质询(challenge)。状态码401 Unauthorized响应中， 肯定带有首部字段WWW-Authenticate。
上述示例中，realm字段的字符串是为了辨别请求URI指定资源所受 到的保护策略。