附录 C　HTTP 首部参考

回想起第一个 HTTP 版本——版本 0.9，还是挺有趣的，因为它没有定义任何首部。尽管这样肯定存在弊端，但不得不为其简洁的优雅而啧啧称奇。

好吧，回到现实中来。现在有很多的 HTTP 首部，有一些是规范中定义的，还有一些是对规范的扩展。本附录提供了一些有关这些正式首部和扩展首部的背景知识，你还可以将其作为本书各种首部的索引使用，说明了这些首部的概念和特性是在正文的什么地方讨论的。这些首部大部分都很简单、直接，是它们之间或者与 HTTP 其他特性之间的交互使得事情变得比较复杂。本附录为所列首部提供了一些背景知识，并指导用户参阅书中详细讨论的对应章节。

本附录列出的首部是从 HTTP 规范、相关文档和我们自己使用 HTTP 报文和因特网上各种服务器和客户端的经验中提取出来的。

这个列表远远称不上完备。Web 中还有很多其他的扩展首部，更别说私有内部网络中使用的那些首部了。尽管如此，我们已经使这个表尽可能地完整了。当前的 HTTP/1.1 规范和官方首部及其规范描述参见 RFC 2616。

Accept

客户端用 Accept 首部来通知服务器可以接受哪些媒体类型。Accept 首部字段的值是客户端可以使用的媒体类型列表。如果 Web 浏览器无法显示 Web 上所有的多媒体对象类型，就可以在请求中包含 Accept 首部，这样浏览器就不会去下载它无法使用的视频或其他对象类型了。

为了防止服务器有多种版本的媒体类型，还可以在 Accept 首部字段中包含一个质量值（q 值）列表，用以告知服务器它优选哪种媒体类型。有关内容协商和 q 值的完整讨论参见第 17 章。

类型　　　　请求首部

注释　　　　“*” 是个特殊值用来通配媒体类型。比如，“*/*” 表示所有类型，“image/*”表示所有的图片类型。

举例　　　　Accept: text/*, image/*

　　　　　　Accept: text/*, image/gif, image/jpeg; q=1

Accept-Charset

客户端用 Accept-Charset 首部来通知服务器它可以接受哪些字符集或哪些是优选字符集。这个请求首部的值是个字符集列表和所列字符集可能的质量值。当服务器上有以多种可接受字符集表示的文档时，可以通过质量值告知服务器哪个字符集是优选的。有关内容协商和 q 值的完整讨论参见第 17 章。

类型　　　　请求首部

注释　　　　与 Accept 首部一样，“*”是个特殊字符。如果有“*”，就表示除了显式地用值设置的字符集之外的所有字符集。如果没有“*”，那么值字段中没有设置的所有字符集的 q 值都默认为零，这不包括字符集isolatin-1，它的默认值为1。

基本语法　　Accept-Charset: 1# ((charset | "*") [";" "q" "=" qvalue])

举例　　　　Accept-Charset: iso-latin-1

Accept-Encoding

客户端用 Accept-Encoding 首部来告知服务器它可以接受哪些编码方式。如果服务器所持有的内容是经过编码的（可能是压缩过的），这个请求首部可以告诉服务器客户端是否会接受它。第 17 章探讨了 Accept-Encoding 首部。

类型　　　　请求首部

基本语法　　Accept-Encoding: 1# ((content-coding | "*") [";" "q" "=" qvalue])

举例　　　　Accept-Encoding:1

　　　　　　Accept-Encoding:gzip

　　　　　　Accept-Encoding: compress;q=0.5,

　　　　　　gzip;q=1

1：这并不是印刷错误。它指的是身份编码——也就是未编码的内容。如果提供了空的 Accept-Encoding 首部，就说明只能接受未编码的内容。

Accept-Language

和其他 Accept 首部一样，客户端可以通过 Accept-Language 请求首部通知服务器可接受或优选哪些语言（比如，内容所使用的自然语言）。第 17 章详尽介绍了 Accept-Language 首部。

类型　　　　请求首部

基本语法　　Accept-Language: 1# (language-range [";" "q" "=" qvalue])

　　　　　　language-range = ((1*8ALPHA * ("-" 1*8ALPHA)) | "*")

举例　　　　Accept-Language: en

　　　　　　Accept-Language: en;q=0.7, en-gb;q=0.5

Accept-Ranges

Accept-Ranges 首部与其他 Accept 首部不同——它是服务器使用的一种响应首部，用来告知客户端它们是否接受请求资源的某个范围。如果这个首部有赋值的话，这个值就说明了服务器允许对指定资源的哪个范围类型进行访问。

客户端可以在没有收到这个首部的情况下，对某资源发起范围请求。如果服务器不支持对那个资源的范围请求，可以以适当的状态码进行响应 2，将 Accept-Ranges 的值设置为 none。服务器可以为普通请求发送 none 值，这样客户端以后就不会发起范围请求了。

2：比如，状态码 416（参见 3.4.4 节）。

第 17 章完整介绍了 Accept-Ranges 首部。

类型　　　　响应首部

基本语法　　Accept-Ranges: 1# range-unit | none

举例　　　　Accept-Ranges: none

　　　　　　Accept-Ranges: bytes

Age

Age 首部可以告诉接收端响应已产生了多长时间。对于原始服务器是在多久之前产生的响应或是在多久之前向原始服务器再次验证响应而言，这是发送端所做的最好的猜测。首部的值是发送端所做的猜测，以秒为单位递增。更多有关 Age 首部的内容参见第 7 章。

类型　　　　响应首部

注释　　　　HTTP/1.1 缓存必须在发送的每条响应中都包含一个 Age 首部。

基本语法　　Age: delta-seconds

举例　　　　Age: 60

Allow

Allow 首部用于通知客户端可以对特定资源使用哪些 HTTP 方法。

类型　　　　响应首部

注释　　　　发送 405 Method Not Allowed 响应的 HTTP/1.1 服务器必须包含 Allow 首部。3

基本语法　　Allow: #Method

举例　　　　Allow: GET, HEAD

3：更多有关状态码 405 的内容参见 3.4 节。

Authorization

Authorization 首部是由客户端发送的，用来向服务器回应自己的身体验证信息。客户端收到来自服务器的 401 Authentication Required 响应后，要在其请求中包含这个首部。这个首部的值取决于所使用的认证方案。有关 Authorization 首部的详细讨论参见第 14 章。

类型　　　　请求首部

基本语法　　Authorization: authentication-scheme #authenticationparam

举例　　　　Authorization: Basic YnJpYW4tdG90dHk6T3ch

Cache-Control

Cache-Control 首部用于传输对象的缓存信息。这个首部是 HTTP/1.1 引入的比较复杂的首部之一。它的值是一个缓存指令，给出了与某个对象可缓存性有关的缓存特有指令。

第 7 章简要介绍了缓存，还说明了与这个首部有关的特定细节。

类型　　　　通用首部

举例　　　　Cache-Control: no-cache

Client-ip

Client-ip 首部是一些比较老的客户端和代理使用的扩展首部，用来传输运行客户端程序的计算机 IP 地址。

类型　　　　扩展请求首部

注释　　　　实现者应该了解这个首部的值所提供的信息是不安全的。

基本语法　　Client-ip: ip-address

举例　　　　Client-ip: 209.1.33.49

Connection

Connection 首部是个多少有点儿过载了的首部，它可能会把你搞晕。这个首部用于扩展了 keep-alive 连接的 HTTP/1.0 客户端，keep-alive 连接用于控制信息。4 在 HTTP/1.1 中，能识别出大部分较老的语义，但这个首部被赋予了新的功能。

4：更多有关 keep-alive 和持久连接的内容参见第 4 章。

在 HTTP/1.1 中，Connection 首部的值是一个标记列表，这些标记对应各种首部名称。应用程序收到带有 Connection 首部的 HTTP/1.1 报文后，应该对列表进行解析，并删除报文中所有在 Connection 首部列表中出现过的首部。它主要用于有代理网络环境，这样服务器或其他代理就可以指定不应传递的逐跳首部了。

close 是一个典型的标记值。这个标记意味着响应结束之后，连接会被关闭。不支持持久连接的 HTTP/1.1 应用程序要在所有请求和响应中插入带有 close 标记的 Connection 首部。

类型　　　　通用首部

注释　　　　虽然 RFC 2616 没有专门声明将 keep-alive 作为连接标记使用，有些（包括那些将 HTTP/1.1 作为版本号发送的）浏览器还是会在发起请求时使用它。

基本语法　　Connection: 1# (connection-token)

举例　　　　Connection: close

Content-Base

服务器可以通过 Content-Base 首部为响应主体部分中要解析的 URL 指定一个基础 URL。5Content-Base 首部的值是一个绝对 URL，可以用来解析在实体内找到的相对 URL。

5：更多有关基础 URL 的信息参见 2.3 节。

类型　　　　实体首部

注释　　　　RFC 2616 中没有定义这个首部。它是早期在 RFC 2068 中定义的，RFC 2068 是一个较早的 HTTP/1.1 规范草案，已经从官方规范中删除了。

基本语法　　Content-Base: absoluteURL

举例　　　　Content-Base: http://www.joes\-hardware.com/

Content-Encoding

Content-Encoding 首部用于说明是否对某对象进行过编码。通过对内容进行编码，服务器可以在发送响应之前将其进行压缩。Content-Encoding 首部的值可以告诉客户端，服务器对对象执行过哪种或哪些类型的编码。有了这个信息，客户端就可以对报文进行解码了。

有时服务器会对某个实体进行多种编码，在这种情况下，必须按照执行的顺序将编码列出来。

类型　　　　实体首部

基本语法　　Content-Encoding: 1# content-coding

举例　　　　Content-Encoding: gzip

　　　　　　Content-Encoding: compress, gzip

Content-Language

Content-Language 首部用来告诉想要理解对象的客户端，应该理解哪种自然语言。比如说，一篇用法语编写的文档就应该有一个表示法语的 Content-Language 值。如果在响应中没有提供这个值，对象就是提供给所有用户的。首部值中有多种语言就说明对象适用于使用所列各种语言的用户。

这里需要说明的是，这个首部的值可能只表示了此对象目标用户的自然语言，而不是对象中包含的所有或者任意一种语言。而且，此首部并不局限于文本或书面数据对象；图像、视频和其他媒体类型也可以用其目标用户的自然语言来标识。

类型　　　　实体首部

基本语法　　Content-Language: 1# language-tag

举例　　　　Content-Language: en

　　　　　　Content-Language: en, fr

Content-Length

Content-Length 首部说明实体主体部分的长度或尺寸。如果对 HEAD HTTP 请求的响应报文中有这个首部，此首部的值就表示如果发送的的话，实体主体部分的长度（实际上并不发送主体）。

类型　　　　实体首部

基本语法　　Content-Length: 1*DIGIT

举例　　　　Content-Length: 2417

Content-Location

Content-Location 首部包含在一个 HTTP 报文中，给出了与报文的实体部分相对应的 URL。对可能有多个 URL 的对象来说，响应报文中可以包含一个 Content-Location 首部，说明用来产生响应的对象的 URL。Content-Location 可以与所请求的 URL 不同。服务器通常会用它将客户端导向或重定向到一个新 URL 上去。

如果 URL 是相对的，就应该相对于 Content-Base 首部加以解释。如果没有提供 Content-Base 首部，就应该使用请求中的 URL。

类型　　　　实体首部

基本语法　　Content-Location: (absoluteURL | relativeURL)

举例　　　　Content-Location: http://www.joes\-hardware.com/index.html

Content-MD5

Content-MD5 首部是服务器用来对报文主体进行报文完整性检查的。只有原始服务器或发起请求的客户端可以在报文中插入 Content-MD5 首部。首部值是（可能需要编码的）报文主体的 MD5 摘要。6

6：MD5 摘要是在 RFC 1864 中定义的。

通过这个首部的值可以端到端地检查数据，在检查传输过程中是否对数据进行了无意的修改时非常有用。不应该将其用于安全目的。

RFC 1864 更详细地定义了这个首部。

类型　　　　实体首部

注释　　　　根据 RFC 1864 的定义，MD5 摘要值是一个Base-64（参见附录E）或 128 位的MD5 摘要。

基本语法　　Content-MD5: md5-digest

举例　　　　Content-MD5: Q2h1Y2sgSW51ZwDIAXR5IQ==

Content-Range

请求传输某范围内的文档时，产生的结果由 Content-Range 首部给出。它提供了请求实体所在的原始实体内的位置（范围），还给出了整个实体的长度。

如果值为“*”，而不是整个实体的长度，就意味着发送响应时，长度未知。

更多有关 Content-Range 的内容请参见第 15 章。

类型　　　　实体首部

注释　　　　以 206 Partial Content 响应码进行响应的服务器，不能包含将“*”作为长度使用的 Content-Range 首部。

举例　　　　Content-Range: bytes 500-999 / 5400

Content-Type

Content-Type 首部说明了报文中对象的媒体类型。

类型　　　　实体首部

基本语法　　Content-Type: media-type

举例　　　　Content-Type: text/html; charset=iso-latin-1

Cookie

Cookie 首部是用于客户端识别和跟踪的扩展首部。第 11 章详细讨论了 Cookie 首部及其用法（还请参见 Set-Cookie）。

类型　　　　扩展请求首部

举例　　　　Cookie: ink=IUOK164y59BC708378908CFF89OE5573998A115

Cookie2

Cookie2 首部是用于客户端识别和跟踪的扩展首部。Cookie2 用于识别请求发起者能够理解哪种类型的 Cookie。在 RFC 2965 中对其进行了更加详细的定义。

第 11 章详细地讨论了 Cookie2 首部及其用法。

类型　　　　扩展请求首部

举例　　　　Cookie2: $version="1"

Date

Date 首部给出了报文创建的日期和时间。服务器响应中要包含这个首部，因为缓存在评估响应的新鲜度时，要用到这个服务器认定的报文创建时间和日期。对客户端来说，这个首部是可选的，但包含这个首部会更好。

类型　　　　通用首部

基本语法　　Date: HTTP-date

举例　　　　Date: Tue, 3 Oct 1997 02:15:31 GMT

　　　　　　HTTP 有几种特定的日期格式。这种格式是在 RFC 822 中定义的，这是 HTTP/1.1 报文的优选格式。但在早期的 HTTP 规范中，没有明确说明日期的格式，因此服务器和客户端的实现者使用了一些其他格式，为了解决这些遗留问题仍然需要支持这些格式。你可能会碰到 RFC 850 中说明的那些日期格式，asctime() 系统调用产生的日期格式。下面是用这些格式所表示的上述日期：

  1. Date: Tuesday, 03-Oct-97 02:15:31 GMT RFC 850 format
    Date: Tue Oct 3 02:15:31 1997 asctime( ) format

大家都不喜欢asctime() 格式，因为它表示的是本地时间，而且没有说明时区（比如，GMT）。总的来说，日期首部应该是 GMT 时间；但健壮的应用程序在处理日期时，应该能够处理那些没有指定时区，或者包含了非 GMT 时间的 Date 值。

ETag

ETag 首部为报文中包含的实体提供了实体标记。实体标记实际上就是一种标识资源的方式。

第 15 章曾探讨过实体标记及其与资源之间的关系。

类型　　　　实体首部

基本语法　　ETag: entity-tag

举例　　　　ETag: "11e92a-457b-31345aa"

　　　　　　ETag: W/"11e92a-457b-3134b5aa"

Expect

客户端通过 Expect 首部告知服务器它们需求某种行为。现在此首部与响应码 100 Continue 紧密相关（参见 3.4.1 节）。

如果服务器无法理解 Expect 首部的值，就应该以状态码 417 Expectation Failed 进行响应。

类型　　　　请求首部

基本语法　　Expect: 1# ("100-continue" | expectation-extension)

举例　　　　Expect: 100-continue

Expires

Expires 首部给出了响应失效的日期和时间。这样，像浏览器这样的客户端就可以缓存一份副本，在这个时间到期之前，不用去询问服务器它是否有效了。

第 7 章曾讨论过 Expires 首部的用法——尤其是，它是如何与缓存关联，怎样与原始服务器进行响应再验证的。

类型　　　　实体首部

基本语法　　Expires: HTTP-date

举例　　　　Expires: Thu, 03 Oct 1997 17:15:00 GMT

From

From 首部说明请求来自何方。其格式就是（RFC 1123 规定的）客户端用户的有效电子邮件地址。

使用 / 填充这个首部存在潜在的隐私问题。客户端实现者在请求报文中包含这个首部之前，应该通知用户，请他们作出选择。有些人会去收集不请自来的邮件报文中携带的电子邮件地址，这可能造成潜在的滥用。因此，未做声明就将此首部广播出去的实现者一定会非常懊悔，他们不得不向愤怒的用户说抱歉。

类型　　　　请求首部

基本语法　　From: mailbox

举例　　　　From: slurp@inktomi.com

Host

客户端通过 Host 首部为服务器提供客户端想要访问的那台机器的因特网主机名和端口号。主机名和端口号来自客户端所请求的 URL。

只要服务器能够在同一台机器（即，在同一个 IP 地址）上提供多个不同的主机名，服务器就可以通过 Host 首部，根据主机名来区分不同的相对 URL。

类型　　　　请求首部

注释　　　　HTTP/1.1 客户端必须在所有请求中包含 Host 首部。所有的 HTTP/1.1 服务器都必须以 400 Bad Request 状态码去响应没有提供 Host 首部的客户端。

基本语法　　Host: host [":" port]

举例　　　　Host: www.hotbot.com:80

If-Modified-Since

If-Modified-Since 请求首部用来发起条件请求。客户端可以用 GET 方法去请求服务器上的资源，而响应则取决于客户端上次请求此资源之后，该资源是否被修改过。

如果对象未被修改过，服务器会回送一条 304 Not Modified 响应，而不会回送此资源。如果对象被修改过，服务器就会像对待非条件 GET 请求一样进行响应。第 7 章详细地讨论了条件请求。

类型　　　　请求首部

基本语法　　If-Modified-Since: HTTP-date

举例　　　　If-Modified-Since: Thu, 03 Oct 1997 17:15:00 GMT

If-Match

与 If-Modified-Since 首部类似，If-Match 首部也可以用于发起条件请求。If-Match 请求使用的是实体标记，而不是日期。服务器将对比 If-Match 首部的实体标记与资源当前的实体标记，如果标记匹配，就将对象返回。

服务器应该用 If-Match 值“*”与某资源拥有的所有实体标记进行匹配。除非服务器上没有这个资源了，否则“*”总会与实体标记相匹配。

类型　　　　请求首部

基本语法　　If-Match: ("*" | 1# entity-tag)

举例　　　　If-Match: "11e92a-457b-31345aa"

If-None-Match

与所有 If 首部一样，If-None-Match 首部可以用于发起条件请求。客户端为服务器提供一个实体标记列表，服务器将这些标记与它拥有的资源实体标记进行比较，只在都不匹配的时候才将资源返回。

这样缓存就可以只在资源已被修改的情况下才更新。通过 If-None-Match 首部，缓存可以用一条请求使它拥有的实体失效，同时在响应中接收新的实体。第 7 章曾讨论过条件请求。

类型　　　　请求首部

基本语法　　If-None-Match: ("*" | 1# entity-tag)

举例　　　　If-None-Match: "11e92a-457b-31345aa"

If-Range

与所有 If 首部一样，If-Range 首部可以用于发起条件请求。应用程序拥有某范围内资源的副本，它要对范围进行再验证，如果范围无效的话，要获取新的资源，在这种情况下会使用这个首部。第 7 章详细讨论了条件请求。

类型　　　　请求首部

基本语法　　If-Range: (HTTP-date | entity-tag)

举例　　　　If-Range: Tue, 3 Oct 1997 02:15:31 GMT

　　　　　　If-Range: "11e92a-457b-3134b5aa"

If-Unmodified-Since

If-Unmodified-Since 和 If-Modified-Since 首部是一对“双胞胎”。在请求中包含此首部就可以发起条件请求。服务器应该去查看首部的日期值，只有在从该首部提供的日期之后，对象都未被修改过，才会返回对象。第 7 章详细介绍了条件 请求。

类型　　　　请求首部

基本语法　　If-Unmodified-Since: HTTP-date

举例　　　　If-Unmodified-Since: Thu, 03 Oct 1997 17:15:00 GMT

Last-Modified

Last-Modified 首部试图提供这个实体最后一次被修改的相关信息。这个值可以说明很多事情。比如，资源通常都是一台服务器上的文件，因此 Last-Modified 值可能就是服务器的文件系统所提供的最后修改时间。另一方面，对于那些动态创建的资源（比如，由脚本创建的资源），Last-Modified 值可能就是创建响应的时间。

服务器要注意，Last-Modified 时间不应该是未来的时间。如果它比 Date 首部中要发送的值还迟，HTTP/1.1 服务器就会将 Last-Modified 时间重置。

类型　　　　实体首部

基本语法　　Last-Modified: HTTP-date

举例　　　　Last-Modified: Thu, 03 Oct 1997 17:15:00 GMT

Location

服务器可以通过 Location 首部将客户端导向某个资源的地址，这个资源可能在客户端最后一次请求之后被移动过，也可能是在对请求的响应中创建的。

类型　　　　响应首部

基本语法　　Location: absoluteURL

举例　　　　Location: http://www.hotbot.com

Max-Forwards

这个首部只能和 TRACE 方法一同使用，以指定请求所经过的代理或其他中间节点的最大数目。它的值是个整数。所有收到带此首部的 TRACE 请求的应用程序，在将请求转发出去之前都要将这个值减 1。

如果应用程序收到请求时，这个首部的值为零，就要向请求回应一条 200 OK 响应，并在实体的主体部分包含原始请求。如果 TRACE 请求中没有 Max-Forwards 首部，就假定没有转发最大次数的限制。

其他 HTTP 方法都应该忽略这个首部。更多有关 TRACE 方法的信息参见 3.3 节。

类型　　　　请求首部

基本语法　　Max-Forwards: 1*DIGIT

举例　　　　Max-Forwards: 5

MIME-Version

MIME 是 HTTP 的近亲。尽管两者存在根本区别，但有些 HTTP 服务器确实构造了一些在 MIME 规范下同样有效的报文。在这种情况下，服务器可以提供 MIME 版本的首部。

尽管 HTTP/1.0 规范中提到过这个首部，但它从未写入官方规范。很多比较老的服务器会发送带有这个首部的报文，但这些报文通常都不是有效的 MIME 报文，这样会让人觉得这个首部令人迷惑且不可信。

类型　　　　扩展的通用首部

基本语法　　MIME-Version: DIGIT "." DIGIT

举例　　　　MIME-Version: 1.0

Pragma

Pragma 首部用于随报文传送一些指令。这些指令几乎可以包含任何内容，但通常会用这些指令来控制缓存的行为。Pragma 首部的目标可以是接收这条报文的所有应用程序，因此代理和网关一定不能将其删除。

最常见的 Pragma 形式——Pragma: no-cache 是一个请求首部，通过它可以迫使缓存在有新鲜副本可用的情况下，向原始服务器请求文档或对其进行再验证。用户点击重新加载 / 刷新按钮时，浏览器就会发出这个首部。很多服务器会将 Pragma: no-cache 作为响应首部发送（和 Cache-Control:no-cache 等价）。尽管这个首部得到了广泛的使用，但从技术上来说，并没有定义过其行为，不是所有的应用程序都支持 Pragma 响应首部。

第 7 章探讨了 Pragma 首部以及 HTTP/1.0 应用程序如何通过它来控制缓存。

类型　　　　请求首部

基本语法　　Pragma: 1# pragma-directive7

举例　　　　Pragma: no-cache

7：规范中定义的唯一的一个 Pragma 指令就是 no-cache，但我们可能会碰到其他作为规范扩展而定义的 Pragma 首部。

Proxy-Authenticate

Proxy-Authenticate 首部的功能类似于 WWW-Authenticate 首部。代理会这个首部来质询发送请求的应用程序，要求其对自身进行认证。第 14 章详细讨论了这个质询 / 响应过程和 HTTP 的其他安全机制。

如果一台 HTTP/1.1 代理服务器发送了一条 407 Proxy Authentication Required 响应，就必须包含 Proxy-Authenticate 首部。

代理和网关在解释所有的 Proxy 首部时要特别小心。通常它们都是逐跳首部，只适用于当前的连接。比如，Proxy-Authenticate 首部会要求对当前的连接进行认证。

类型　　　　响应首部

基本语法　　Proxy-Authenticate: challenge

举例　　　　Proxy-Authenticate: Basic realm="Super Secret Corporate FinancialDocuments"

Proxy-Authorization

Proxy-Authorization 首部的功能与 Proxy-Authorization 首部类似。客户端应用程序可以用它来响应 Proxy-Authenticate 质询。更多有关质询 / 响应安全机制工作原理的内容参见第 14 章。

类型　　　　请求首部

基本语法　　Proxy-Authorization: credentials

举例　　　　Proxy-Authorization: Basic YnJpYW4tdG90dHk6T3ch

Proxy-Connection

Proxy-Connection 首部的语义与 HTTP/1.0 Connection 首部类似。在客户端和代理之间可以用它来指定与连接（主要是 keep-alive 连接）有关的选项。8 它并不是一个标准的首部，标准委员会把它当作一个临时首部。但它得到了浏览器和代理的广泛使用。

8：更多有关 keep-alive 和持久连接的内容参见第 14 章。

浏览器实现者创建了 Proxy-Connection 首部，来解决客户端发送的 HTTP/1.0 Connection 首部被哑代理盲转发的问题。收到被盲转发的 Connection 首部的服务器会将客户端连接的功能与代理连接的功能混淆起来。

客户端知道要经过代理传输时，就会发送 Proxy-Connection 首部，而不是 Connection 首部。服务器如果无法识别 Proxy-Connection 首部，就会将其忽略，这样，对首部进行盲转发的哑代理就不会带来任何问题了。

如果在从客户端到服务器的路径上有多个代理，这种解决方法就会有问题。如果第一个代理将首部盲转发给第二个能够理解它的代理，那么第二个代理就会像服务器看到 Connection 首部一样，无法理解。

这是 HTTP 工作组的解决方案存在的问题——他们将其作为一种黑客工具，可以解决单个代理的问题，但无法解决更大的问题。尽管如此，这种方式确实能够处理一些比较常见的情况，而且由于网景的 Navigator 和微软的 Internet Explorer 的较老版本都实现了这个首部，因而代理的实现者也需要对其进行处理，更多信息参见第 4 章。

类型　　　　通用首部

基本语法　　Proxy-Connection: 1# (connection-token)

举例　　　　Proxy-Connection: close

Public

服务器可以用 Public 首部告知客户端它支持哪些方法。今后客户端发起的请求就可以使用这些方法了。代理收到服务器发出的带有 Public 首部的响应时，要特别小心。这个首部说明的是服务器支持的方法，而不是代理的，因此代理在将响应发送给客户端之前，要对首部的方法列表加以编辑，或者将此首部删除。

类型　　　　响应首部

注释　　　　RFC 2616 中没有定义这个首部。它是之前在HTTP/1.1 规范的早期草案 RFC 2068 中定义的，而官方规范已经将其删除了。

基本语法　　Public: 1# HTTP-method

举例　　　　Public: OPTIONS, GET, HEAD, TRACE, POST

Range

在请求某实体的部分内容中会用到 Range 首部。它的值说明了报文所包含实体的范围。

请求某范围内的文档可以更有效地对大型对象发出请求（分段对其发出请求），或者更有效地从传输错误中恢复（允许客户端请求没有完成的那部分资源）。第 15 章详细说明了范围请求和能实现范围请求的首部。

类型　　　　实体首部

举例　　　　Range: bytes=500-1500

Referer

在客户端请求中插入 Referer 首部，可以使服务器知道客户端是从哪里获得其请求的 URL。这是一种对服务器有益的自愿行为，这样服务器就可以更好地记录请求，或执行其他任务了。Referer 的拼写错误要回溯到 HTTP 的早期，令世界各地以英语为母语的文字编辑们万分沮丧。

浏览器所做的工作相当简单。如果在主页 A 上点击一个链接，进入主页 B，浏览器就会在请求中插入一个带有值 A 的 Referer 首部。只有在你点击链接的时候，浏览器才会插入 Referer 首部；自己输入的 URL 中不会包含 Referer 首部。

因为有些页面是私有的，所以这个首部会有隐私问题。尽管有些只是毫无根据的猜想，但 Web 服务器及其管理者确实可以通过这个首部看到你来自何方，这样他们就能更好地追踪你的浏览行为了。因此，HTTP/1.1 规范建议应用程序编写者让用户来选择是否传输这个首部。

类型　　　　请求首部

基本语法　　Referer: (absoluteURL | relativeURL)

举例　　　　Referer: http://www.inktomi.com/index.html

Retry-After

服务器可以用 Retry-After 首部告知客户端什么时候重新发送某资源的请求。这个首部可以与 503 Service Unavailable（服务不可用）状态码配合使用，给出客户端可以重试其请求的具体日期和时间（或者秒数）。

服务器还可以在将客户端重定向到资源时，通过这个首部通知客户端在对重定向的资源发送请求之前需要等待的时间。9 对那些正在创建动态资源的服务器来说，这个首部是非常有用的，服务器可以通过它将客户端重定向到新创建的资源，并给出了资源创建所需的时间。

9：更多有关服务器重定向响应的信息参见表 3-8。

类型　　　　响应首部

基本语法　　Retry-After: (HTTP-date | delta-seconds)

举例　　　　Retry-After: Tue, 3 Oct 1997 02:15:31 GMT

　　　　　　Retry-After: 120

Server

Server 首部与 User-Agent 首部类似。它为服务器提供了一种向客户端标识自己的方式。它的值就是服务器名字和一个可选的服务器注释。

Server 首部是用来识别服务器软件的，而且包含了与软件有关的附加注释，所以其格式比较随意。如果编写的软件与服务器标识自己的方式有关，就应该测试服务器软件，看看它会发回什么内容，因为这些标记会随软件及其发布版本的不同而有所不同。

像 User-Agent 首部一样，如果较老的代理或网关在 Server 首部中插入了相当于 Via 首部的内容，千万不要感到吃惊。

类型　　　　响应首部

基本语法　　Server: 1* (product | comment)

举例　　　　Server: Microsoft-Internet-Information-Server/1.0

　　　　　　Server: Websitepro/1.1f (s/n wpo-07d0)

　　　　　　Server: apache/1.2b6 via proxy gateway CERN-HTTPD/3.0 libwww/2.13

Set-Cookie

Set-Cookie 首部是 Cookie 首部的搭档。第 11 章介绍了这个首部的用法。

类型　　　　扩展响应首部

基本语法　　Set-Cookie: command

举例　　　　Set-Cookie: lastorder=00183; path=/orders

　　　　　　Set-Cookie: private_id=519; secure

Set-Cookie2

Set-Cookie2 首部是对 Set-Cookie 首部的扩展。第 11 章详细了探讨了这个首部的用法。

类型　　　　扩展响应首部

基本语法　　Set-Cookie2: command

举例　　　　Set-Cookie2: ID="29046"; Domain=".joes-hardware.com"

　　　　　　Set-Cookie2: color=blue

TE

TE 首部的名字起得不太好（本应该将其命名为 Accept-Transfer-Encoding），它的功能与 Accept-Encoding 首部类似，但它是用于传输编码的。TE 首部还可 以用来说明客户端能否处理位于分块编码的响应拖挂中的首部。更多有关 TE 首部、分块编码和拖挂的内容参见第 15 章。

类型　　　　请求首部

注释　　　　如果这个值为空，就只接受分块传输编码。特定标记“trailers”说明分块响应中可以接受 Trailer 首部。

基本语法　　TE: # (transfer-codings)

　　　　　　transfer-codings= "trailers" | (transfer-extension [accept-params])

举例　　　　TE:

　　　　　　TE: chunked

Trailer

Trailer 首部用于说明报文拖挂中提供了哪些首部。第 15 章详细说明了分块编码和拖挂。

类型　　　　通用首部

基本语法　　Trailer: 1#field-name

举例　　　　Trailer: Content-Length

Title

Title 首部不像人们所期望的那样，会给出实体标题的规范化首部。这个首部是早期 HTTP/1.0 扩展的一部分，主要用于 HTML 页面，这些 HTML 页面有着服务器可以使用的明确的标题标记。但即使不是大部分，也有很多 Web 媒体类型没有便捷的标题解析手段，这个标题的用处有限。因此，尽管网络上一些比较老的服务器仍然在忠实地发送这个首部，但它从未成为官方规范。

类型　　　　响应首部

注释　　　　RFC 2616 中没有定义 Title 首部。最早是在HTTP/1.0 草案（http://www.w3.org/Protocols/HTTP/HTTP2.html）中定义的，但之后就从官方规范中删除了。

基本语法　　Title: document-title

举例　　　　Title: CNN Interactive

Transfer-Encoding

如果要通过某些编码来安全地传送 HTTP 报文主体，报文中就要包含 Transfer-Encoding 首部。它的值是一个对报文主体执行过的编码的列表。如果进行了多种编码，就将其按序排列。

Transfer-Encoding 首部与 Content-Encoding 首部不同，因为服务器或其他中间应用程序是通过执行 Transfer-Encoding 对要传输的报文进行编码的。

第 15 章介绍过传输编码。

类型　　　　通用首部

基本语法　　Transfer-Encoding: 1# transfer-coding

举例　　　　Transfer-Encoding: chunked

UA-(CPU, Disp, OS, Color, Pixels)

这些 User-Agent 首部是非标准的，现在也不常见了。它们提供了客户端机器的相关信息，以便服务器更好地进行内容选择。比如，如果服务器知道用户机器只有一个 8 位彩色显示器，服务器就可以选择适合那类显示器的图片了。

有些首部给出了与客户端相关的信息，不使用这些首部就无法获知这些信息。所有这样的首部都有一些安全方面的隐患（更多信息参见第 14 章）。

类型　　　　扩展请求首部

注释　　　　RFC 2616 没有定义这些首部，而且不推荐使用这些首部。

基本语法　　"UA" "-" ("CPU" | "Disp" | "OS" | "Color" | "Pixels") ":" machine-value

　　　　　　machine-value = (cpu | screensize | os-name |displaycolor-depth)

举例　　　　UA-CPU: ×86　　　　　　客户端机器的CPU

　　　　　　UA-Disp: 640, 480, 8 　 客户端显示器的尺寸和色彩深度

　　　　　　UA-OS: Windows 95　　　客户端机器的操作系统

　　　　　　UA-Color: color8　 　 　客户端显示器的色彩深度

　　　　　　UA-Pixels: 640×480 　 　客户端显示器的尺寸

Upgrade

Upgrade 首部为报文发送者提供了一种手段，使其指定另一种可能完全不同协议并将此意愿向外广播。比如，HTTP/1.1 客户端可以向服务器发送一条 HTTP/1.0 请求，其中包含了值为“HTTP/1.1”的 Update 首部，这样客户端就可以测试一下服务器是否也使用 HTTP/1.1 了。

如果服务器也可以使用 HTTP/1.1，就可以发送一条适当的响应，让客户端知道可以使用新的协议。这样就提供了一种切换使用其他协议的有效方式。现在大部分服务器都只兼容 HTTP/1.0，通过这种策略，在判定服务器确实能够使用 HTTP/1.1 之前，客户端就不会用很多的 HTTP/1.1 首部骚扰服务器了。

服务器发送 101 Switching Protocols 响应时，必须包含这个首部。

类型　　　　通用首部

基本语法　　Upgrade: 1# protocol

举例　　　　Upgrade: HTTP/2.0

User-Agent

客户端应用程序用 User-Agent 首部来标识其类型，与服务器的 Server 首部类似。它的值就是应用程序的名称，可能还会有一个描述性注释。

这个首部的格式比较随意。它的值会随客户端应用程序和发布版本的不同而有所不同。有时这个首部甚至会包含一些有关客户端机器的信息。

与 Server 首部一样，如果较老的代理或网关应用程序在 User-Agent 首部中插入了与 Via 首部等效的内容，请不要感到惊奇。

类型　　　　请求首部

基本语法　　User-Agent: 1* (product | comment)

举例　　　　User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Vary

服务器通过 Vary 首部来通知客户端，在服务器端的协商中会使用哪些来自客户端请求的首部。10 它的值是一个首部列表，服务器会去查看这些首部，以确定将什么内容作为响应发回给客户端。

10：更多与内容协商有关的内容参见第 17 章。

根据客户端 Web 浏览器特性来发送特定 HTML 页面的服务器就是一例。为某个 URL 发送这些特定页面的服务器会包含一个 Vary 首部，以说明它是查看了请求的 User-Agent 首部之后，才决定发送什么内容作为响应的。

代理缓存也会使用 Vary 首部。更多有关 Vary 首部与已缓存的 HTTP 响应关联方式的信息参见第 7 章。

类型　　　　响应首部

基本语法　　Vary: ("*" | 1# field-name)

举例　　　　Vary: User-Agent

Via

Via 首部用于在报文经过代理和网关时对其进行跟踪。这是一个信息首部，通过它可以看出哪些应用程序在对请求和响应进行处理。

报文在向客户端或服务器传输的途中经过某个 HTTP 应用程序时，这个应用程序可以通过 Via 首部对通过它传输的报文进行标记。这是个 HTTP/1.1 首部，而很多较老的应用程序会在请求和响应的 User-Agent 或 Server 首部插入类似 Via 的字符串。

如果报文是通过多个中间应用程序传输的，那么每个应用程序都会向其 Via 字符串中附加一些内容。必须通过 HTTP/1.1 代理和网关来插入 Via 首部。

类型　　　　通用首部

基本语法　　Via: 1# (received-protocol received-by [comment])11

举例　　　　Via: 1.1 joes-hardware.com ( Joes-Server/1.0)

11：完整的 Via 头部语法参见 HTTP/1.1 规范。

上面这个例子说明报文是通过运行在机器 joes-hardware.com 上的 Joes 的服务器软件 1.0 版传输的。Via 首部的格式应该如下所示：

  1. HTTP-Version machine-hostname (Application-Name-Version)

Warning

Warning 首部可以给出更多与请求过程中所发生情况有关的信息。它为服务器提供了一种手段，可以发送除状态码或原因短语之外的其他信息。HTTP/1.1 规范中定义了以下几种警告代码。

  • 101 响应过时了

当知道一条响应报文已过期时（比如，原始服务器无法进行再验证时），就必须包含这条警告信息。

  • 111 再验证失败

如果缓存试图与原始服务器进行响应再验证，但由于缓存无法抵达原始服务器造成了再验证失败，那就必须在发给客户端的响应中包含这条警告信息。

  • 112 断开连接操作

通知性警告信息。如果缓存到网络的连接被删除了就应该使用此警告信息。

  • 113 试探性过期

如果新鲜性试探过期时间大于 24 小时，而且返回的响应使用期大于 24 小时，缓存中就必须包含这条警告信息。

  • 199 杂项警告

收到这条警告的系统不能使用任何自动响应。报文中可能，而且很可能应该包含一个主体，其中携带了为用户提供的额外信息。

  • 214 使用了转换

如果中间应用程序执行了任何会改变响应内容编码的转换，就必须由任意一个中间应用程序（比如代理）来添加这条警告。

  • 299 持久杂项警告

接收这条警告的系统不能进行任何自动的回应。错误中可能包含一个主体部分，它为用户提供了更多的信息。

类型　　　　响应首部

基本语法　　Warning: 1# warning-value

举例　　　　Warning: 113

WWW-Authenticate

WWW-Authenticate 首部用于 401 Unauthorized 响应，向客户端发布一个质询认证方案。第 14 章深入讨论了 WWW-Authenticate 首部及其在 HTTP 基本质询 / 响应认证系统中的使用方法。

类型　　　　响应首部

基本语法　　WWW-Authenticate: 1# challenge

举例　　　　WWW-Authenticate: Basic realm="Your Private Travel Profile"

X-Cache

X 开头的都是扩展首部。Squid 用 X-Cache 首部来通知客户端某个资源是否可用。

类型　　　　扩展响应首部

举例　　　　X-Cache: HIT

X-Forwarded-For

很多代理服务器（比如，Squid）会用这个首部来说明某条请求都被转发给了谁。与前面提到的 Client-ip 首部类似，这个请求首部说明了请求是从哪个地址发出的。

类型　　　　扩展请求首部

基本语法　　X-Forwarded-For: addr

举例　　　　X-Forwarded-For: 64.95.76.161

X-Pad

这个首部用来解决某些浏览器中与响应首部长度有关的 bug。它在响应报文的首部填充了一些字节，以解决这个 bug。

类型　　　　扩展通用首部

基本语法　　X-Pad: pad-text

举例　　　　X-Pad: bogosity

X-Serial-Number

X-Serial-Number 首部是个扩展首部。某些较老的 HTTP 应用程序会用它向 HTTP 报文中插入许可软件的序列号。

它基本上已经没什么用处了，它只是作为 X 开头的首部的一个示例列在这里。

类型　　　　扩展通用首部

基本语法　　X-Serial-Number: serialno

举例　　　　X-Serial-Number: 010014056