HTTP Developer’s Handbook 中文翻译 Chapter 5: 第三节 请求（消息）头部（一）

原文地址： HTTP Developer’s Handbook 中文翻译 Chapter 5: 第三节 请求（消息）头部（一）

 

Request Headers

每一个HTTP请求都有一个消息头部（HTTP headers）的集合。这些消息头部提供了那些能够使Web服务器更好地满足请求的信息。尽管这些头部被分成 请求头部，通用头部和实体头部3类，但是每一个头部都有着自己的特有的功能。

Request headers （请求头部）只适用于HTTP请求。HTTP/1.1定义了19个请求头部。我将逐一介绍这些头部，另外还有一个已经被广泛支持并且定义在RFC2109“HTTP状态管理机制”中的Cookie头。

The Accept Header

Accept头的基本功能就是告知Web服务器该请求接受哪些种类的内容类型（Content type），以及在可接受的内容类型的权重（即更倾向于接受哪一种类型的内容）。

使用第一节给出的例子，当我们在Google中搜索“HTTP”关键字时，你可以检查该请求中的Accept头。

1 2 3

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,         text/plain;q=0.8, video/x-mng,image/png,image/jpeg,image/gif;q=0.2,         text/css,*/*;q=0.1

拆解来看，你会发现有几部分拥有相同的格式：

1 2 3 4

text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 text/plain;q=0.8 video/x-mng,image/png,image/jpeg,image/gif;q=0.2 text/css,*/*;q=0.1

这些条目中的每一个都是由“,”分隔的一或多个内容类型（也可以说是媒体类型（media type））后面紧跟一个由“;”分隔的权重系数（q）组成的。q值越高，请求越倾向于获得其“;”之前的类型的内容。这个q值可以取0到1之间（包含0和1）的任何数，如果没有指定q值的话默认为1。被赋值为0则用于提醒服务器哪些是我不接受的内容类型。但是由于浏览器需要尽可能的兼容已经过时的内容类型，指定不接受某些类型的做法是不常见的。

每一种内容类型都被分成类型（type）和子类型（subtype）。*号可以被用于像 */html这样的类型中，也可以被用于像 text/* 这样的子类型中。常会见到 */*这样的用法。这基本上就允许了接收任何类型的内容（尽管这通常会被赋予最低的权重），因此也是浏览器最后的应急措施。如果浏览器没有明确指定的可接受的内容类型，那么所有内容类型的权重将被赋值为0。就类似于浏览器会无视他们不认识的标签一样。

Accept头并不是用来告诉浏览器允许它支持某一指定类型的内容的。浏览器原生支持哪些种类的内容是由它自己决定的，一些插件能够增强浏览器的支持能力，像是能够浏览Adobe Acrobat文档或者Flash动画的插件。当浏览器不能决定如何处理接收到的内容时，它一般会尝试让用户来决定是打开文件还是下载到硬盘。

如果Web服务器由于Accept系列头部(Accept, Accept-Charset, Accept-Encoding 和 Accept-Language)的限制而不能满足请求的话，将会返回一个406 Not Acceptable响应。

The Accept-Charset Header

所有的Accept系列的头部都有着相似的语法，因此就语义来讲之前关于Accept头的讨论也适用于该系列中的其他头部。

Accept-Charset头部告知Web服务器哪些字符编码是可以接受的，而且也可以使用q值来指定其更乐于接受的字符编码。用第一节的例子，你可以检查其Accept-Charset头部的内容。

1	Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66

你可以看到这里也是用了*号来匹配所有的字符编码。虽然有着相同q值，但是因为明确指定了ISO-8859-1和utf-8，它们拥有更高的优先级。

ISO-8859-1编码默认被假设为q值为1。另外要注意的一点是，事实上HTTP消息本身（除去实体内容）是由ISO-8859-1编码的。能够被使用的字符集是注册在IANA（Internet Assigned Numbers Authority，互联网编号分配组织）上的（详情请见http://www.iana.org/）。

Note
字符集（Character set）和字符编码（character encoding）条目是可以相互替换使用的。然而，不要假设Accept-Encoding头与字符编码有关系。下面会介绍Accept-Encoding头部，所以要注意它和Accept-Charset的不同。

The Accept-Encoding Header

Accept-Encoding头部说明了哪些内容编码是浏览器有能力解码的。这与Accept-Charset头部中指定的字符集的概念完全不同。

为了确保能够协同工作，与字符编码一样，Accept-Encoding头部可以使用的值也是注册在IANA的。

最常用的内容编码是一些压缩类的，比如像是gzip（GNU zip）之类的通用压缩算法。这能够使内容传输的更快，因为内容被压缩的更小了。

同Accept头的语法一样，在Accept-Encoding头中也可以使用q值来指定更希望接受的内容编码。

The Accept-Language Header

Accept-Language头允许浏览器指明用户更希望使用的语言。一般的格式是一个主要语种的标签后面跟着一个可选的子标签。例如en和en-US。可用的语言标签也是有IANA来维护的。

1	Accept-Language: en

本例中只接受英语，因为没有列出子类型，所以这会匹配所有的英语子类型比如en-US。

The Authorization Header

Authorization头部允许浏览器向Web服务器验证自己的身份。HTTP授权机制将在Chapter 18有更详细的介绍。

当浏览器向那些敏感的或者受用户名和密码保护的资源发出请求时会发生一系列事件。第一次的请求将会被服务器返回一个401 Unauthorized响应来通知浏览器它必须提供一个正确的Authorization头部来获得访问权限。为了提供这些信息，浏览器将会提示用户需要输入用户名和密码。

一旦浏览器通过这种方式成功通过了一个Web服务器的授权，它将表现的就如同以后的请求都不再需要验证了一样。然而，由于Web的无状态特性，每一次请求都必须包含Authorization头部，否则服务器仍然会返回401 Unauthorized响应。现代浏览器会存储授权证书，对之前受保护的域名下的URL的所有HTTP请求添加Authorization头部。因为这种做法是利用了浏览器的内存，所以这个方便的功能只能持续到浏览器关闭。用户不会察觉到接下来的请求都还进行了验证。当你调试HTTP授权机制的时候这是十分重要的因素，因为如果你接收到了401响应却没有被浏览器提示需要输入用户名和密码，那么就说明浏览器是在使用错误的证书来经行验证。重启浏览器就可以解决这种情况了。

Note
关于WWW-Authenticate response header的资料可以在Chapter 6“HTTP Response”中找到。

相关文章:

• HTTP Developer’s Handbook 中文翻译 Chapter 5:第一节 HTTP请求的语法 (28.1)
• HTTP Developer’s Handbook 中文翻译 Chapter 5:第二节 HTTP请求方法 (16.5)
• HTTP Developer’s Handbook 中文翻译 Chapter 5: 第三节 请求（消息）头部（二） (13.2)

 

本博客文章由LiZn创作或分享，以创作公用CC 姓名标示-非商业性-相同方式分享 3.0 Unported 授权条款共享。 
转载请注明 转自: HTTP Developer’s Handbook 中文翻译 Chapter 5: 第三节 请求（消息）头部（一）