HTTP权威指南 - HTTP响应和请求首部参考

HTTP首部参考

本附录列出的首部是从HTIP规范、相关文档和我们自己使用HTIP报文和因特网
上各种服务器和客户端的经验中提取出来的。
这个列表远远称不上完备。Web中还有很多其他的扩展首部，更别说私有内部网
络中使用的那些首部了。尽管如此，我们已经使这个表尽可能地完整了。

Accept

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

类型	请求首部
注释	“” 是个特殊值用来通配媒体类型。比如，"/"表示所有类型，"image/"表示所有的图片类型。
举例	Accept: text/*, image/gif, image/jpeg; q=l

Accept-Charsat

客户端用Accept-Charset首部来通知服务器它可以接受哪些字符集或哪些是优选字符集。这个请求首部的值是个字符集列表和所列字符集可能的质量值。当服务器上有以多种可接受字符集表示的文档时，可以通过质量值告知服务器哪个字符集是优选的。

类型	请求首部
注释	与Accept首部一样， “＊ ” 是个特殊字符。如果有"*"’ 就表示除了
	显式地用值设置的字符集之外的所有字符集。如果没有"*"’ 那么值
	字段中没有设置的所有字符集的q值都默认为零，这不包括字符集isolatin-1, 它的默认值为1。
基本语法	Accept-Charset: 1# (( charset I “*”) ["; " “q” "="qvalue])
举例	Accept-Charset: iso-latin-1

Accept-Encoding

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

类型	请求首部
基本语法	Accept-Encoding: 1# ((content-coding \| “*”) [";" “q” = " qvalue ))
举例	Accept-Encoding:
	Accept-Encoding:gzip
	Accept-Encoding: compress;q=0.5,
	gzip;q=1

Accept-Language

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

类型	请求首部
基本语法	Accept-Language: 1# (language-range [";" “q” “=” qvalue])
	language-range = ((18ALPHA * ( “-” 1SALPHA)) I “*”)
举例	Accept-Language: en
	Accept-Language: en;q=0.7, en-gb;q=0.5

Accept-Ranges

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

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

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

类型	响应首部
基本语法	Accept-Ranges: l# range-unit I 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响应的HTIP/1.l服务器必须包含Allow首部。
基本语法	Allow: #Metho

Authorization

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

类型	请求首部
基本语法	Authorization: authentication-scheme #authentication param
举例	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/LO客户端，keep-alive连接用千控制信息。

在HITP/1.1中，能识别出大部分较老的语义，但这个首部被赋予了新的功能。

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

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

类型	通用首部
注释	虽然RFC 2616 没有专门声明将keep-alive作为连接标记使用，有些
	（包括那些将HITP/1.1作为版本号发送的）浏览器还是会在发起请求时使用它。
基本语法	Connection: 1# (connection-token)
举例	Connection: close

Content-Base

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

类型	实体首部
注释	RFC 2616中没有定义这个首部。它是早期在RFC 2068中定义的，RFC
	2068是一个较早的HTIP/1.1规范草案，已经从官方规范中删除了。
基本语法	Content-Base: absoluteURL
举例	Content-Base: http://www.joes-hardware.com/

Content-Encoding

Content-Encoding首部用千说明是否对某对象进行过编码。通过对内容进行编码，服务器可以在发送响应之前将其进行压缩。Conten亡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首部说明实体主体部分的长度或尺寸。如果对HEADHTIP请求的响应报文中有这个首部，此首部的值就表示如果发送的的话，实体主体部分的长度（实际上井不发送主体）。

类型	实体首部
基本语法	Content-Length: l*DIGIT
举例	Content-Length: 2417

Content-Location

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

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

类型	实体首部
基本语法	Content-Location: (absoluteURL I relativeURL)
举例	Content-Location: http://www.joes-hardware.com/index.html

Content一MD5

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

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

类型	实体首部
注释	根据RFC 1864的定义，MD5摘要值是一个Base-64 (参见附录E)或128位的MD5摘要。
基本语法	Content-MD5: md5-digest
举例	Content-MOS: Q2hlY2sgSW51ZwDIAXRSIQ==

Content-Range

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

如果值为＂＊＂，而不是整个实体的长度，就意味着发送响应时，长度未知。
更多有关Content-Range的内容请参见第15章。

类型	实体首部
注释	以206 Partial Content响应码进行响应的服务器，不能包含将"*"作为
	长度使用的Content-Range首部。
举例	Conten尸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=IUOK164y59BC708378908CFF890E5573998All5

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 ()系统调用产生的日期格式。下面是用这些格式所表示的上述日期：

Date: Tuesday, 03-0ct-97 02:15:31 GMT RFC 850 format
Date: Tue Oct 3 02:15:31 1997 asctime(J format

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

ETag

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

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

类型	实体首部
基本语法	ETag: entity-tag
举例	ETag: “lle92a-457b-31345aa”
	ETag: W/“lle92a-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。

类型	请求首部
注释	HITP/1.1客户端必须在所有请求中包含Host首部。所有的H’ITP/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-M吐ch首部的实体标记与资源当前的实体标记，如果标记匹配，就将对象返回。

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

类型	请求首部
基本语法	If-Match: ("*" I 1# entity-tag)
举例	If-Match: “lle92a-457b-31345aa”

If-None-Match

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

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

类型	请求首部
基本语法	If汉one-Match: ("*" I 1# entity-tag)
举例	If-None-Match: "11e92a-457b-31345aa "

If-Range

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

类型	请求首部
颐基本语法If-Range: (HTTP-date I entity-tag.)
举例	If-Range: Tue, 3 Oct 1997 02:15:31 GMT
	If-Range: “lle92a-457b-3l34b5aa”

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首部，就假定没有转发最大次数的限制。

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

类型	请求首部
基本语法	Max-Forwards: l*DIGIT
举例	Max-Forwards: 5

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

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

类型	请求首部
基本语法	Pragma: 1# pragma-directive
举例	Pragma: no-cache

Proxy-Authenticate

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

如果一台HTTP/I.I代理服务器发送了一条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质询。更多有关质询I响应安全机制工作原理的内容参见第14章。

类型	请求首部
基本语法	Proxy-Authorization: credentials
举例	Proxy心uthorization: Basic YnJp吓4tdG90dHk6T3ch

Proxy-Connection

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

浏览器实现者创建了Proxy-Connection首部，来解决客户端发送的HTIP/1.0Connection首部被哑代理盲转发的问题。收到被盲转发的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章详细说明了范围请求和能实现范围请求的首部。

Referer

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

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

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

类型	请求首部
基本语法	Referer: (absoluteURL I relativeURL)
举例	Referer: http://www.inktomi.com/index.html

Retry-After

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

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

类型	响应首部
基本语法	Retry-After: (HTTP-date I 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 I comment)
举例	Server: Microsoft-Internet-Information-Server/1.0
	Server: Websitepro/1.lf (s/n wpo-07d0)
	Server: apache/1. 2b6 via proxy gateway CERN-HTTPD/3. O
	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

TB

TE首部的名字起得不太好（本应该将其命名为Accept-Transfer卫ncoding),

它的功能与Accep亡Encoding首部类似，但它是用千传输编码的。TE首部还可
以用来说明客户端能否处理位于分块编码的响应拖挂中的首部。更多有关TE首部、
分块编码和拖挂的内容参见第15章。

类型	请求首部
注释	如果这个值为空，就只接受分块传输编码。特定标记"trailers"说明分块响应中可以接受Trailer首部。
基本语法	TE: # (transfer-codings) l transfer-codings= “trailers” I (transfer-extension[accept-params])
举例	TE:
	TE: chunked

Trailer

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

类型	通用首部
基本语法	Trailer: l#field-name
举例	Trailer: Content-Length

Title

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

类型	响应首部
注释	RFC 2616中没有定义Title 首部。最早是在HTTP/LO草案(http://
	www.w3.org/Protocols/HTIP/HTTP2.html)中定义的．但之后就从官方
	规范中删除了。
基本语法	Title: document-title
举例	Title: CNN Interactive

Transfer-Encoding

如果要通过某些编码来安全地传送HTTP报文主体，报文中就要包含Transfer-Encoding首部。它的值是一个对报文主体执行过的编码的列表。如果进行了多种
编码，就将其按序排列。
Transfer-Encoding首部与Content-Encoding首部不同，因为服务器或其他中
间应用程序是通过执行Transfer心ncoding对要传输的报文进行编码的。
第15章介绍过传输编码。

类型	通用首部
基本语法	Transfer-Encoding: 1# transfer-coding
举例	Transfer-Encoding: chunked

UA一(CPU, Diep, OS, Color, Pixels)

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

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

类型	扩展请求首部
注释	RFC 2616没有定义这些首部，而且不推荐使用这些首部。
基本语法	“UA” “-” (“CPU” I “Disp” I “OS” I “Color” I “Pixels”)
	“:” machine-value
	machine-value = (cpu I screensize I os-name !displaycolor-depth)
举例	UA-CPU: X 86 客户端机界的CPU
	U凡Disp: 640, 480, 8 客户瑞显示器的尺寸和色彩深度
	UA-0S: Windows 95 客户端机界的操作系炕
	UA-Color: colors
	UA-Pixels: 640 X 480
	客户端显示器的色彩深度
	客户端显示另的尺寸

Upgrade

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

如果服务器也可以使用HTTP/1.1, 就可以发送一条适当的响应，让客户端知道可以使用新的协议。这样就提供了一种切换使用其他协议的有效方式。现在大部分服务器都只兼容HTTP/1.0, 通过这种策略，在判定服务器确实能够使用HTTP/1.l之前，客户端就不会用很多的HTT P/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 I comment)
举例	User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; WindowsNT 5.0)

Vary

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

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

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

类型	响应首部
基本语法	Vary: ("*" I 1# field-name)
举例	Vary: User-Agent

Via

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

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

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

类型	通用首部
基本语法	Via: 1# (received-protocol received-by [comment]) 11
举例	Via: 1.1 joes-hardware.com (Joes-Server/1.0)

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

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

Warning

Warning首部可以给出更多与请求过程中所发生情况有关的信息。它为服务器提供
了一种手段，可以发送除状态码或原因短语之外的其他信息。HTIP/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 基本质询I 响应认证系统中的使用方法。

类型	响应首部
基本语法	WWW-Authenticate: 1# challenge
举例	WWW-Authenticate: Basic realm=“Your Private Travel Profile”

X-Cache

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

类型	扩展响应首部
举例	X-Cache: HIT

X-Forwarded-Por

很多代理服务器（比如，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