标签 http 下的文章

Accept

客户端用 Accept 首部来通知服务器 可以接受哪些媒体类型，其值就是客户端支持的媒体类型列表，比如 image/gif 就是表示客户端支持 gif 格式的图片， * 则是一个特殊的值，用来通配媒体类型，比如 */* 表示所有媒体，image/* 则表示所有的图片，同时，还可以添加一个质量值 q 来告诉浏览器优先选择哪种媒体类型。

示例

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Accept-Charset

客户端用 Accept-Charset 首部来通知服务器，它可以接受哪些字符集或者哪些优选字符集，其值为多个字符集列表以及字符集可能的质量值，当服务器上有以多种可接受字符集表示的文档时，可以通过质量值告知服务器哪个字符集是优选的，该首部同样有一个 * 通配符。

示例

Accept-Charset: iso-latin-1

Accept-Encoding

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

示例

Accept-Encoding: gzip, compress;q=0.5

Accept-Language

客户端用 Accept-Language 表示可接受或者优选哪些语言。

示例

Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4

Accept-Ranges

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

客户端可以在没有收到这个首部的情况下，对某资源发起范围请求。如果服务器法巴拉圭对那个资源的范围请求，可以以适当的状态码（比如 416）进行响应，奖 Accept-Ranges 的值设置为 none ，客户端以后就不会（也不应该）再发起范围请求了。

应用场景

该首部最常见的应用场景就是断点下载，当我们从网络上下载一个大小为 4096 bytes 的文件时，可能下载到 2048 bytes时，网络中断了，这个时候，如果再次下载，我们就可以通过一个客户端的 Range 首部告诉服务器，我只需要下载 2049 bytes 之后的数据即可，前面的数据已经有了（这个在后面会讲到），当然，这需要服务器返回一个正确的 Accept-Ranges 值 bytes。

另一个常见的场景就是在做 RESTFul 接口时，比如一个用于查询所有用户列表的接口 /users，可能数据库里面总共有 10000 条记录，但是我们不可能一次性就全部返回，这个时候，服务器可以返回一个 Accept-Ranges: items ，告诉客户端，你可以以 items 类型对该资源进行部分下载。

示例

Accept-Ranges: bytes

Age

Allow

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

示例

Allow: GET, HEAD

Authorization

Authorization 首部是由客户端发送的，用来向服务器回应自己的身份验证信息，客户端收到来自服务器的 401 Authentication Required 响应后，要在其请求中包含这个首部，这个首部的值 取决非于所使用的认证方案。

示例

Authorization: Basic YnJpYW4tdG90dHk6T3ch

说明

在有一些时候，我们可能也不会使用这个首部，而是使用自己定义的相类似的首部，比如在信用生活的项目里面我们使用的就是 X-Auth-Token，这个时候，但是使用这种自定义的首部之后，通用的客户端就无法为我们进行任何建议或处理了，就像在浏览器里面，若服务器返回 401 Authentication Required，这个时候，浏览器表现为弹出一个输入用户名和密码的输入框 ，用户输入之后，浏览器会对其进行简单的 Base64 编码，然后直接重新发起一次请求（本次请求会带上如上面示例所示的首部），但是对于服务器来讲，因为认证并不是通过 Authorization 首部进行的，所以还是会返回 401 响应。

Cache-Control

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

示例

Cache-Control: no-cache

Client-ip

这是一个在一些比较老的客户端和代理上面会出现的首部，用于表示运行当前客户端或者代理的计算机的IP地址。

示例

Client-ip: 10.106.4.199

Connection

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

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

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

示例

Connection: close

Content-Base

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

示例

Content-Base: http://www.onmr.com/

Content-Encoding

Content-Encoding 首部用于说明是否对某对象进行过编码，通过对内容进行编码，服务器可以在发送响应之前将其进行压缩，然后通过 Content-Encoding 首部的值告诉客户端，服务器对对象执行过哪种或者哪些类型的编码，有了这个信息，客户端就可以对报文进行编码了，这个值，理论上来讲应该是由客户端发送的 Accept-Encoding 首部中所有支持的编码类型的一个子集。

示例

Content-Encoding: compress, gzip

Content-Language

Content-Language 首部用来告诉想要理解对象的客户端，应该理解哪种自然语言，比如说，一篇用法语编写的文档就应该有一个表示法语的 Content-Language 值。

示例

Content-Language: en

Content-Length

Content-Length 首部说明了主体部分的长度或尺寸，如果对 HEAD 请求的响应报文中带上这个首部，则这个首部就告诉客户端，如果要发送内容的话，那么内容主体的长度就是这个值。

示例

Content-Length: 2417

Content-Location

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

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

示例

下面的示例就是信用生活中，信用卡信息管理接口 /api/v1/discovery/creditcards ，当我使用 POST 请求，向服务器发送了张新卡片详情数据之后，服务器完成数据的校验与保存，然后返回一个 Content-Location ，告诉客户端，新的内容的位置在哪里：

Content-Location:/api/v1/discovery/creditcards/1600

Content-MD5

Content-MD5 首部是服务器用来对报文主体进行报文完整性检查的，只有原始服务器或发起请求的客户端可以在报文中插入 Content-MD5 首部，首部值就是报文主体的 MD5 摘要（根据 RFC 1864 的定义，MD5 摘要值是一个 Base64 或者 128 位的 MD5 摘要。

示例

Content-MD5: YnJpYW4tdG90dHk6T3ch

Content-Range

请求传输某范围内的文档时，产生的结果由 Content-Range 首部给出，它提供了请求实体所在的原始实体内的位置（范围），还给出了整体实体的长度。如果值为 *，而不是整个实体的长度，就意味首发送响应时，长度未知（这个我们在使用浏览器下载文件的时候，绝大多数情况下，我们都是可以根据当前网速知道剩余下载时间的，但是有一些下载，我们却不知道下载时间，这就是因为，在下载时，服务器明确表示了内容长度未知引起的）。

示例

下面的示例就表示了，内容的长度单位为 bytes，总长度为 5400 bytes ，而本次响应的内容为整个主体对象第 500 - 999 bytes 间的内容。

Content-Range: bytes 500-999 / 5400

应用场景

这个首部在我来宜人贷的这段时间内，还没有看到哪个项目或者团队在使用，但是在我自己的项目里面使用到了，我自己项目的接口是完全基于 RESUful 建议的，这里面就以 /user/users 接口为例来讲讲，该接口的 GET 请求用于查询数据库中的所有用户，默认情况下，服务器会返回查询到的前20条记录，现在假如整个库中有 1000 个用户，那么， /user/users 这个资源主体大小就是 1000，因为这里面的大小单位不再是 bytes ，所以，我们自己定义了一个单位 items，当客户端 GET /user/users 时，会得到下面这样的首部：

Content-Range: items 0-19/1000

此时，客户端已经得到它所需要的所有信息了：

  1. 当前资源返回的是第0至第19个
  2. 资源总条目（items）数为 1000

在接下来的访问过程中，客户端就可以发起请求，获取其它范围的内容了，比如下面这样：

Range: items=20-39

这时，服务器就知道，此次请求需要查询的是第20至第39个条目

说明

关于 RESTful 中的分页，我现在的解决方案如下：

  • 请求格式：Range: items=start-end
  • 响应格式：Content-Range: items start-end/total
Range 首部

Range 首页由客户端发送请求时携带，用于标识此次请求需要服务器端返回哪个区间的数据，Range的取值方式如下：

  1. items=0-9：取结果集中的 第0至第9 个子集
  2. items=1000-：取结果集中 第1000及其以后所有数据 的子集
  3. items=-500：取结果集中 最后500个 子集
  4. items=0-9,20-29：取结果集中 第0-9个 以及 第20-29个 两个子集的合集
  5. items=0-9,-9：取结果集中 第0-9个 以及 最后9个 两个子集的合集
Content-Range 首部

Content-Range 首部是由服务器在返回结果的响应时，携带的首部，用于表示此次返回的数据的范围，其值如下：

Content-Range: items 0-9/100

详细的说明可以见 http://git.onmr.com/grassroots/grassroots-api-docs/blob/master/structure.md。

关于 Range 首部，会在 Range 首部中专门细说一下。

Content-Type

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

示例

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

Cookie

Cookie 首部是用于客户端识别和跟踪的扩展首部。

示例

Cookie: sessionid=IDFIOSDUFSDFLKIU@#IOL#KKJoi

Cookie2

Cookie2 首部是用于客户端识别和跟踪的扩展首部，Cookie2 用于识别请求发起者能够理解哪种类型的 Cookie1。

示例

Cookie2: $version="1"

Date

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

HTTP 有几种特定的日期 格式，这种格式是在 RFC 822中定义的，这是 HTTP/1.1 报文的优选格式，但是在早期的HTTP规范中，没有明确说明日期的格式，因此服务器和客户端的实现者使用了一些其他 格式，为了解决这些遗留问题仍然需要支持这些格式：

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

示例

Date: Thu, 07 Jan 2015 15:15:15 GMT

ETag

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

示例

ETag: "11e92a-457b-31345aa"
ETag: W/"11e92a-457b-31345aa"
W/ 前缀广播一个 弱 实体标记，对于弱实体标记来说，只有当关联 的实体在语义上发生了重大改变时，标记才会变化 。

Expect

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

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

示例

Expect: 100-continue

Expires

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

示例

Expires: Thu, 07 Jan 2015 15:15:15 GMT

From

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

示例

From: name@domain.com

Host

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

如果一台服务器上面服务着多个网站，每一个网站绑定了一个独立的域名，这个时候，服务器软件就需要通过 Host 首部来判断用户是需要访问当前该服务器上面的那一个网站了。

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

示例

Host: onmr.com:80

If-Modified-Since

If-Modified-Since 请求首部用来发起条件请求，客户端可以用 GET 方法去请求服务器上的资源，而响应则取决于客户端上次请求此资源之后，该资源是否被修改过，如果对象未被修改过，服务器就会回送一条 304 Not Modified 响应，而不会回送此资源，如果对象对修改过，则服务器就会像非条件 GET 请求一样进行响应。

示例

If-Modified-Since: Thu, 07 Jan 2015 15:15:15 GMT

If-Match

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

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

示例

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

If-None-Match

与所有 If 首部一样，If-None-Match 首部可以用于发起条件请求，客户端为服务器提供 一个实体标记列表，服务器将这些标记与它拥有的资源实体标记进行比较，只在都不匹配的时候才将资源返回。这样缓存就可以只在资源已被修改的情况下才更新。通过 If-None-Match 首部，缓存可以用一条请求使它拥有 的实体失效，同时在响应中接收新的实体。

示例

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

If-Range

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

示例

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

If-Unmodified-Since

If-Unmodified-Since 与 If-Modified-Since 是一对，该首部查询时，未被修改过才返回对象。

示例

If-Unmodified-Since: Thu, 03 Oct 2015 17:17:17 GMT

Last-Modified

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

Location

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

示例

Location: http://www.onmr.com/press/http-headers

Max-Forwards

这个首部必须和 Trace 方法一同使用，以指定请示所经过的代理或者其它中间节点的最大数目，它的值是一个整数，所有收到带有此首部的 Trace 请示，都需要在请示转发出去之前，将该值减1。如果应用程序在收到请示时，这个首部的值为0,就要向请示回应一条 200 OK响应，并在实体的主体部分包含原始请示。

示例

Max-Forwards: 5

MIME-Version

MIME-Version 用于提供服务器支持的 MIME 版本，老服务器才可能存在，没有进入标准中。

Pragma

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

最常见的形式，比如用户点击刷新按扭或者重新加载时，浏览器一般都会带上 Pragma: no-cache 首部，用于强制在有新鲜副本可用的情况下，向原始服务器请示文档或对其进行再验证。很多服务器也会向客户端发送 Pragma: no-cache 首部的响应（作用与 Cache-Control: no-cache 等价）

规范中唯一一个被定义的指令就是 no-cache

Proxy-Authenticate

Proxy-Authenticate 与 WWW-Authenticate 类似，当代理服务器发送了一条 407 Proxy Authentication Required 响应时，发起请示的应用程序就必须包含 Proxy-Authenticate 首部。

示例

Proxy-Authenticate: Basic realm="Yirendai Super User"

Proxy-Authorization

Proxy-Authorization 被客户端用来响应代理服务器的 Proxy-Authenticate 声明

Proxy-Connection

Proxy-Connection 与 HTTP/1.0 Connection 首部类似，

Public

Public 首部可让服务器告知客户端其支持哪些方法，今后客房端就可以在发起的请示中使用这些方法了。

示例

Public: OPTIONS, GET, HEAD, TRACE, POST

Range

在请示某个实体的部分内容时，会使用到这个首部

示例

Range: bytes=500-1000

Referer

在客户端的请求中插入 Referer 首部，可以使服务器知道客房端是从哪里获取到其请示的 URL的，这是一种对服务器有益的自愿行为，这样服务器就可以更好的记录请求，或执行其它任务。

浏览器所做的工作非常简单，如果在主页Ａ上点击了一个金田白立，进入主页Ｂ，那么浏览器就会在请求Ｂ的请求中带有一个 Referer 首部，其值为主页Ａ的ＵＲＬ。

Retry-After

服务器通过 Retry-After 首部告知客房端在什么时候可以重新发送某资源的请求。

Server

Server 与 User-Agent 类似，服务器使用该首部来标识自己。

Set-Cookie

Set-Cookie 用于告知客户端设置 Cookie

Set-Cookie2

对 Set-Cookie 首部的扩展

TE

Accept-Transfer-Encoding ，类似于 Accept-Encoding，只不过它用于定义传输编码。

Trailer

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

示例

Trailer: Content-Length

Title

Title 发送 HTML 文档的标题（非标准）

Transfer-Encoding

Transfer-Encoding 定义报文的传输编码。

示例

Transfer-Encoding: chunked

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

非标准

Upgrade

User-Agent

Vary

Via

Warning

WWW-Authenticate

X-Cache

X-Forwarded-For

X-Pad

X-Serial-Number