常见http头部 (二)

常见http头部 (二)：

Last-Modified
Last- Modified首部试图提供这个实体最后一次被修改的相关信息。这个值可以
说明很多事情。比如,资源通常都是一台服务器上的文件,因此Iast- Modified
值可能就是服务器的文件系统所提供的最后修改时间。另一方面,对于那些动态创建
的资源(比如,由脚本创建的资源),Last- Modified值可能就是创建响应的时间。
服务器要注意,Last- Modified时间不应该是未来的时间。如果它比pate首部中
要发送的值还迟,HTTP/1.1服务器就会将Last-Modified时间重置。

基本语法last-Modified:HTTP-date

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

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

基本语法 Location: absoluteURL

举例
Locationhttp://www.hotbot.com

Max-Forwards
这个首部只能和 TRACE方法一同使用,以指定请求所经过的代理或其他中间节点
的最大数目。它的值是个整数。所有收到带此首部的 TRACE请求的应用程序,在
将请求转发出去之前都要将这个值减1。
如果应用程序收到请求时,这个首部的值为零,就要向请求回应一条200OK响应,
并在实体的主体部分包含原始请求。如果 TRACE请求中没有Max- Forwards首
部,就假定没有转发最大次数的限制. 其他HTTP方法都应该忽略这个首部。

基本语法Max- Forwards:1* DIGIT
举例
Max-Forwards: 5

MIME-Version
MIME是HTTP的近亲。尽管两者存在根本区别,但有些HTP服务器确实构造了
一些在MIME规范下同样有效的报文。在这种情况下,服务器可以提供MIME版本的首部
尽管HTTP/1.0规范中提到过这个首部,但它从未写入官方规范。很多比较老的服
务器会发送带有这个首部的报文,但这些报文通常都不是有效的MIME报文,这样
会让人觉得这个首部令人迷惑且不可信。
扩展的通用首部

基本语法MME- Version: DIGIT I. I DIGI
举例
MIME-Version: 1.0

Pragma
Pragma首部用于随报文传送一些指令。这些指令几乎可以包含任何内容,但通常
会用这些指令来控制缓存的行为。 Pragma首部的目标可以是接收这条报文的所有
应用程序,因此代理和网关一定不能将其删除。
最常见的 Pragma形式 Pragma: no-cache 是一个请求首部,通过它可以迫使
缓存在有新鲜副本可用的情况下,向原始服务器请求文档或对其进行再验证。用户
点击重新加载/刷新按钮时,浏览器就会发出这个首部。很多服务器会将 Pragma:
no- cache作为响应首部发送(和 Cache- Control:no- cache等价)。尽管这个首
部得到了广泛的使用,但从技术上来说,并没有定义过其行为,不是所有的应用程
序都支持 Pragma响应首部

基本语法Pragma: 1# pragma-directive
举例
Pragma: no-cache

Proxy-Authenticate
Proxy- Authenticate首部的功能类似于wwW-Authenticate首部。代理会这个
首部来质询发送请求的应用程序,要求其对自身进行认证。
如果一台HTTP/1.1代理服务器发送了一条407 Prox yAuthenticationR equired响应,
就必须包含 proxy- Authenticate首部。
代理和网关在解释所有的 Proxy首部时要特别小心。通常它们都是逐跳首部,只
适用于当前的连接。比如, Proxy- Authenticate首部会要求对当前的连接进行认证

基本语法 proxy- Authenticate:cha11enge
举例
Proxy-Authenticate: Basic realm=“Super Secret Corporate FinancialDocuments”

Proxy-Authorization
Poxy- Authorization首部的功能与 Proxy- Authorization首部类似。客户端
应用程序可以用它来响应 Proxy- Authenticate质询。
基本语法 Proxy- Authorization: credentials
举例
proxy-Authorization: Basic YnJpYW4taG9odHk6T3ch

Proxy-Connection
PRoxy-Connection首部的语义与HTTP/1.0Connection首部类似。在客户端和
代理之间可以用它来指定与连接(主要是 keep-alive连接)有关的选项。它并不是
个标准的首部,标准委员会把它当作一个临时首部。但它得到了浏览器和代理的
广泛使用。
浏览器实现者创建了 Proxy- Connection首部,来解决客户端发送的HTTp/1.0
onnection首部被哑代理盲转发的问题。收到被盲转发的 Connection首部的服务器会将客户端连接的功能与代理连接的功能混淆起来。

客户端知道要经过代理传输时,就会发送 proxy- Connection首部,而不是Connection
首部。服务器如果无法识别Poxy- Connection首部,就会将其忽略,这样,对首部进行盲转发的哑代理就不会带来任何问题了。
如果在从客户端到服务器的路径上有多个代理,这种解决方法就会有问题。如果第
个代理将首部盲转发给第二个能够理解它的代理,那么第二个代理就会像服务器看到 Connection首部一样,无法理解。

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

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

举例
Proxy-Connection: close

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

注释 RFC2616中没有定义这个首部。它是之前在HTP/1.1规范的早期草案, RFC2068中定义的,而官方规范已经将其删除了。
基本语法
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服务器及其管理者确实可以通过这个首部看到你来自何方,这样他们就
能更好地追踪你的浏览行为了。因此,HTP/1.1规范建议应用程序编写者让用户来
选择是否传输这个首部。

基本语法 Referer:( absoluteR| relativeuRI)
举例
Referer:http://www.inktomi.com/index.html

Retry-After
服务器可以用 Ret- After首部告知客户端什么时候重新发送某资源的请求。这
个首部可以与503 Service Unavailable(服务不可用)状态码配合使用,给出客户端
可以重试其请求的具体日期和时间(或者秒数)。
服务器还可以在将客户端重定向到资源时,通过这个首部通知客户端在对重定向的
资源发送请求之前需要等待的时间。°对那些正在创建动态资源的服务器来说,这个
首部是非常有用的,服务器可以通过它将客户端重定向到新创建的资源,并给出了
资源创建所需的时间。
类型
响应首部
基本语法Retry-After:(HTTP-datedelta-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. lf(s/n wpo-07d0)
Server: apache/1.2b6 via proxy gateway Cern-HttpD/3.0 libwww/2.13

Set-Cookie
set-Cookie首部是 Cookie首部的搭档

基本语法set- Cookie: command

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

set-Cookie
set-Cookie2首部是对set- Cookie首部的扩展。
Set-Cookie2: command
基本语法
举例
set-Cookie2: ID=29046; Domain=.joes-hardware com"
set-Cookie2: color=blue

TE
TE首部的名字起得不太好(本应该将其命名为cept- ransfer- Encoding),

它的功能与 Accept- Encoding首部类似,但它是用于传输编码的。TE首部还可
以用来说明客户端能否处理位于分块编码的响应拖挂中的首部。更多有关TE首部、

注释 如果这个值为空,就只接受分块传输编码。特定标记“ trailers说明分块响应中可以接受 Trailer首部。
基本语法
TE:#(transfer-codings transfer-codings= trailers | (transfer-extension [accept-params])

举例
TE :
TE: chunked
Trailer

Trailer首部用于说明报文拖挂中提供了哪些首部。

基本语法Trai1er:1#fie1d-name
举例
Trailer: Content-Length

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

基本语法 Title: document-title
举例
Title: CNN Interactive

Transfer–Encoding

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

Transfer- Encoding首部与Content-Encoding首部不同,因为服务器或其他中

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

User-Agent
客户端应用程序用 User-Agent首部来标识其类型,与服务器的 Server首部类似。它的值就是应用程序的名称,可能还会有一个描述性注释。
这个首部的格式比较随意。它的值会随客户端应用程序和发布版本的不同而有所不同。有时这个首部甚至会包含一些有关客户端机器的信息。
与 Server首部一样,如果较老的代理或网关应用程序在User- Agent首部中插入了与via首部等效的内容,请不要感到惊奇。

基本语法Uer- Agent:1·( product commen
举例
User-Agent: Mozilla/4.0(compatible; MSIE 5.5; WindowsNT5.0)

Varry
服务器通过vary首部来通知客户端,在服务器端的协商中会使用哪些来自客户端
请求的首部。它的值是一个首部列表,服务器会去查看这些首部,以确定将什么
内容作为响应发回给客户端
根据客户端Web浏览器特性来发送特定HTML页面的服务器就是一例。为某个
URL发送这些特定页面的服务器会包含一个vary首部,以说明它是查看了请求的
User-Agent首部之后,才决定发送什么内容作为响应的。

代理缓存也会使用vaxy首部

基本语法Vary:("*” | 1# field-name)
举例
Vary: User-Agent

via
ⅵia首部用于在报文经过代理和网关时对其进行跟踪。这是一个信息首部,通过它
可以看出哪些应用程序在对请求和响应进行处理。
报文在向客户端或服务器传输的途中经过某个HTTP应用程序时,这个应用程序可
以通过va首部对通过它传输的报文进行标记。这是个HrTP1首部,而很多较
老的应用程序会在请求和响应的User- Agent或 Server首部插入类似via的字符串。
如果报文是通过多个中间应用程序传输的,那么每个应用程序都会向其via字符串
中附加一些内容。必须通过HTTP/11代理和网关来插入Via首部。

基本语法
Via: 1# (received-protocol received-by [comment])
举例
via: 1.1 joes-hardware.com( Joes-Server/1.0)

Warning

Warning首部可以给出更多与请求过程中所发生情况有关的信息。它为服务器提供
了一种手段,可以发送除状态码或原因短语之外的其他信息。HTTP/1.1规范中定义
了以下几种警告代码
101响应过时了
当知道一条响应报文已过期时(比如,原始服务器无法进行再验证时),就必须包含这条警告信息
111再验证失败
如果缓存试图与原始服务器进行响应再验证,但由于缓存无法抵达原始服务器造成
了再验证失败,那就必须在发给客户端的响应中包含这条警告信息

112断开连接操作
通知性警告信息。如果缓存到网络的连接被删除了就应该使用此警告信息。
113试探性过期
如果新鲜性试探过期时间大于24小时,而且返回的响应使用期大于24小时,缓存
中就必须包含这条警告信息。
199杂项警告
收到这条警告的系统不能使用任何自动响应。报文中可能,而且很可能应该包含
个主体,其中携带了为用户提供的额外信息
214使用了转换
如果中间应用程序执行了任何会改变响应内容编码的转换,就必须由任意一个中间
应用程序(比如代理)来添加这条警告。
299持久杂项警告
接收这条警告的系统不能进行任何自动的回应。错误中可能包含一个主体部分,它
为用户提供了更多的信息。

基本语法 Warning:1# warning- value
举例
Warning: 113

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

基本语法 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)会用这个首部来说明某条请求都被转发给了谁。与
前面提到的C1ient-ip首部类似,这个请求首部说明了请求是从哪个地址发出的。

基本语法x- Forwarded-For:addr
举例
x-Forwarded-For: 64.95.76.161

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

基本语法 x-pad: pad-text
举例
X-Pad: bogosit

x-Serial-Number
x-Seria1-Number首部是个扩展首部。某些较老的HTTP应用程序会用它向HTTP
报文中插入许可软件的序列号。它基本上已经没什么用处了

基本语法 X-Serial-Number: serialno
举例

X-Serial-Number: 010014056

备注：在http 头中定义自己的key时，作为扩展的首部，一般需要以X-开头
例如： X-Token: “xxxxxxxxxxxxx”