一文带你看清HTTP全部概念

上一篇文章咱们大体讲解了一下 HTTP 的基本特征和使用，你们反响很不错，那么本篇文章咱们就来深究一下 HTTP 的特性。咱们接着上篇文章没有说完的 HTTP 标头继续来介绍（此篇文章会介绍全部标头的概念，但没有深刻底层）

HTTP 标头

先来回顾一下 HTTP1.1 标头都有哪几种

HTTP 1.1 的标头主要分为四种，通用标头、实体标头、请求标头、响应标头，如今咱们来对这几种标头进行介绍

通用标头

HTTP 通用标头之因此这样命名，是由于与其余三个类别不一样，它们不是限定于特定种类的消息或者消息组件（请求，响应或消息实体）的。HTTP 通用标头主要用于传达有关消息自己的信息，而不是它所携带的内容。它们提供通常信息并控制如何处理和处理消息。

尽管通用标头不会限定因而请求仍是响应报文，可是某些通用标头大部分或所有用于一种特定类型的请求中。也就是说，若是某个通用标头出如今请求报文中，那么大部分通用标头都会显示在该请求报文中。响应报文也是同样的。

先列出来一个清单，讲明咱们都须要介绍哪些通用标头

• Cache-Control
• Connection
• Date
• Pragma
• Trailer
• Transfer-Encoding
• Upgrade
• Via
• Warning

Cache-Control

缓存（Cache）是计算机领域里的一个重要概念，是优化系统性能的利器。不只计算机中的 CPU 为了提升指令执行效率从而选择使用寄存器做为辅助，计算机网络一样存在缓存，下面咱们就来介绍一下计算机网络中的缓存。

Cache-Control 是通用标头的指令，它可以管理如何对 HTTP 的请求或者响应使用缓存。

由于计算机网络中是能够有第三者出现的，也就是缓存服务器，这个指令经过影响请求/响应中的缓存服务器从而达到控制缓存的目的；不只有缓存服务器，还有浏览器内部缓存也会影响链路的缓存。

这个标头中能够出现许多单独的指令，其详细信息能够在 RFC 2616 中找到，即便这是常规标头，某些指令也只能出如今请求或响应中。下表提供了一个 Cache-Control 选项的总结并告诉你如何去使用

请注意，在 Cache-Control 标头中只能出现一个指令，可是在消息中能够出现多个这样的标头。

上面这个表格其实会有四种分类

• 可缓存性： 它们分别是 no-cache、no-store、private 和 public
• 缓存有效性时间： 它们分别是 max-age、s-maxage、max-stale、min-fresh
• 从新验证并从新加载： 它们分别是 must-revalidate 和 proxy-revalidate
• 其余： 它们分别是 only-if-cached 和 no-transform

分别对表格中的内容进行一下详细介绍

no-cache

no-cache 很容易和 no-store 混淆，通常都会把 no-cache 认为是不缓存，其实不是这样。

使用 no-cache 指令的目的是为了防止从缓存中返回过时的资源，例以下图所示

Cache-Control: no-cache

举个例子你就明白了，No-Cache 就至关因而吃着碗里的，占着锅里的，若是锅里还有新的肉片，就先吃锅里的，若是锅里没有新的，再吃本身的，这里锅里的就至关因而源服务器产生的，碗里的就至关因而缓存的。

no-store

no-store 才是真正意义上的不缓存，每次服务器接受到客户端的请求后，都会返回最新的资源给客户端。

Cache-Control: no-store

max-age

max-age 能够用在请求或者响应中，当客户端发送带有 max-age 的指令时，缓存服务器会判断本身缓存时间的数值和 max-age 的大小，若是比 max-age 小，那么缓存有效，能够继续给客户端返回缓存的数据，若是比 max-age 大，那么缓存服务器将不能返回给客户端缓存的数据。

Cache-Control: max-age=60

若是 max-age = 0，那么缓存服务器将会直接把请求转发到服务器

Cache-Control: max-age=0

注意：这个 max-age 的值是相对于请求时间的

must-revalidate

表示一旦资源过时，缓存就必须在原始服务器上没有成功验证的状况下才使用其过时的数据。

Cache-Control: must-revalidate

no-store 、no_cache 、 must-revalidate 和 max-age 能够一块儿看，下面是一个这四个标头的流程图

public

public 属性只出如今客户端响应中，表示响应能够被任何缓存所缓存。在计算机网络中，分为两种缓存，共享缓存和私有缓存，以下所示

Cache-Control: public

private

当指定 private 指令后，响应只以特定的用户做为对象，这与 public 的用法相反，缓存服务器只对特定的客户端进行缓存，其余客户端发送过来的请求，缓存服务器则不会返回缓存。

Cache-Control: private

s-maxage

s-maxage 指令的功能和 max-age 指令的功能相同，不一样点之处在于 s-maxage 不能用于私有缓存，只能用于多用户使用的公共服务器，对于同一用户的重复请求和响应来讲，这个指令没有任何做用。

Cache-Control: s-maxage=60

min-fresh

min-fresh只能出如今请求中，min-fresh 要求缓存服务器返回 min-fresh 时间内的缓存数据。例如 Cache-Control:min-fresh=60，这就要求缓存服务器发送60秒内的数据。

Cache-Control: min-fresh=60

max-stable

max-stable 只能出如今请求中，表示客户端会接受缓存数据，即便过时也照常接收。

Cache-Control: max-stable=60

only-if-cached

这个标头只能出如今请求中，使用 only-if-cached 指令表示客户端仅在缓存服务器本地缓存目标资源的状况下才会要求其返回。

Cache-Control: only-if-cached

proxy-revalidate

proxy-revalidate 指令要求全部的缓存服务器在接收到客户端带有该指令的请求返回响应以前，必须再次验证缓存的有效性。

Cache-Control: proxy-revalidate

no-transform

使用 no-transform 指令规定不管是在请求仍是响应中，缓存都不能改变实体主体的媒体类型。

Cache-Control: no-transform

Connection

HTTP 协议使用 TCP 来管理链接方式，主要有两种链接方式，持久性链接 和 非持久性链接。

持久性链接

持久性链接指的是一次会话完成后，TCP 链接并未关闭，第二次再次发送请求后，就再也不须要创建 TCP 链接，而是能够直接进行请求和响应。它的通常表示形式以下

Connection: keep-alive

从 HTTP 1.1 开始，默认使用持久性链接。

keep-alive 也是一个通用标头，通常 Connection 都会和 keep-alive 一块儿使用，keep-alive 有两个参数，一个是 timeout；另外一个是 max，它们的主要表现形式以下

Connection: Keep-Alive
Keep-Alive: timeout=5, max=1000

• timeout: 指的是空闲链接必须打开的最短期，也就是说此次请求的链接时间不能少于5秒，
• max: 指的是在链接关闭以前服务器所可以收到的最大请求数。

非持久性链接

非持久性链接表示一次会话请求/响应后关闭链接的方式。HTTP 1.1 以前使用的链接都是非持久链接，也就是

Connection: close

Date

Date 是一个通用标头，它能够出如今请求标头和响应标头中，它的基本表示以下

Date: Wed, 21 Oct 2015 07:28:00 GMT

表示的是格林威治标准时间，这个时间要比北京时间慢八个小时

Pragma

Pragma是 http 1.1 以前版本的历史遗留字段，仅做为与 http 的向后兼容而定义。它的通常形式以下

Pragma: no-cache

只用于客户端发送的请求中。客户端会要求全部的中间服务器不返回缓存的资源。

若是全部的中间服务器都以实现 HTTP /1.1为标准，那么直接使用 Cache-Control: no-cache 便可，若是不是的话，就要包含两个字段，以下

Cache-Control: no-cache
Pragma: no-cache

Trailer

首部字段 Trailer 会事先说明在报文主体后记录了哪些首部字段。该首部字段可应用在 HTTP/1.1 版本分块传输编码时。通常用法以下

Transfer-Encoding: chunked
Trailer: Expires

以上用例中，指定首部字段 Trailer 的值为 Expires，在报文主体以后（分块长度 0 以后）出现了首部字段 Expires。

Transfer-Encoding

Transfer-Encoding 属于内容协商的范畴，下面会具体介绍一下内容协商，如今先作个预告：Transfer-Encoding 规定了传输报文所采用的编码方式

注意：HTTP 1.1 的传输编码方式仅对分块传输有效，可是 HTTP 2.0 就再也不支持分块传输，而提供了本身更有效的数据传输机制。

Transfer-Encoding: chunked

Transfer-Encoding 也属于 Hop-by-hop（逐跳） 首部 ，下面来回顾一下，HTTP 报文标头除了能够根据属性所在的位置分为 通用标头、请求标头、响应标头 和 实体标头；还能够按照是否被缓存分为 端到端首部(End-to-End) 和 逐跳首部(Top-to-Top)。

除了下面八种属于逐跳首部外，其他都属于端到端首部

Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、Trailer、TE、Transfer-Encoding、Upgrade

下面回到讨论中来，Transfer-Encoding 用于两个节点之间传输消息，而不是资源自己。在多个节点传输消息的过程当中，每一段消息的传输均可以使用不一样的 Transfer-Encoding。如图所示

Transfer-Encoding 支持文件压缩，若是你想要以文件压缩后的形式发送的话。Transfer-Encoding 全部可选类型以下

• chunked： 数据按照一系列块发送，在这种状况下，将省略 Content-Length 标头，并在每一个块的开头，须要以十六进制填充当前块的长度，后跟 '\r\n'，而后是块自己，而后是另外一个'\r\n'。当将大量数据发送到客户端而且在请求已被彻底处理以前，可能没法知道响应的总大小时，分块编码颇有用。 例如，在生成由数据库查询产生的大型 HTML 表时或在传输大型图像时。 分块的响应看起来像这样

HTTP/1.1 200 OK 
Content-Type: text/plain 
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n 
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n 
\r\n

终止块一般是0。紧随Transfer-Encoding 后面的是 Trailer 标头， Trailer 可能为空。

• compress： 使用 Lempel-Ziv-Welch(LZW) 算法的格式。值名称取自 UNIX 压缩程序，该程序实现了该算法。如今几乎没有浏览器使用这种内容编码了，由于这个专利在 2003 年就停掉了。
• deflate：使用 zlib(在 RFC 1950 定义) 结构和 deflate 压缩算法
• gzip： 使用Lempel-Ziv编码（LZ77）和32位CRC的格式。这最初是 UNIX gzip 程序的格式。HTTP / 1.1标准还建议出于兼容性目的，支持此内容编码的服务器应将 x-gzip 识别为别名。
• identity： 使用身份功能（即无压缩或修改）。

也能够列出多个值，以逗号分隔，相似一个集合列表

Transfer-Encoding: gzip, chunked

Upgrade

首部字段 Upgrade 用于检测 HTTP 协议及其余协议是否可以使用更高的版本进行通讯，其参数值能够用来指定一个彻底不一样的通讯协议。

上图用例中，首部字段 Upgrade 指定的值为 TLS/1.0。请注意此处两个字段首部字段的对应关系，Connection 的值被指定为 Upgrade。
Upgrade 首部字段产生做用的对象仅限于客户端和临近服务器之间。所以，使用首部字段 Upgrade 时，还须要额外指定 Connection: Upgrade。
对于附有首部字段 Upgrade 的请求，服务器可用 101 Switching Protocols 状态码做为响应返回。

Via

使用 Via 是为了跟踪客户端和服务器之间的请求/响应路径，避免请求循环以及可以识别请求/响应链中发送者协议的功能。Via 字段由代理服务器添加，不管是正向代理仍是反向代理，而且能够出如今请求标头和响应标头中。它用于跟踪消息转发。例以下图所示

Via 后面的的 1.1, 1.0 表示接收服务器上的 HTTP 版本，Via 首部是为了跟踪路径，常常和 TRACE 方法一块儿使用。

Warning

注意：Warning 字段即将被弃用

查阅 Warning (https://github.com/httpwg/http-core/issues/139) and Warning: header & stale-while-revalidate (https://github.com/whatwg/fetch/issues/913) 获取更多细节

Warning 通用 HTTP 标头一般会告知用户一些与缓存相关的问题的警告

HTTP/1.1 中定义了 7 种警告。它们分别以下

请求标头

请求标头用于客户端发送 HTTP 请求到服务器中所使用的字段，下面咱们一块儿来看一下 HTTP 请求标头都包含哪些字段，分别是什么意思。下面会介绍

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Authorization
• Expect
• From
• Host
• If-Match
• If-Modified-Since
• If-None-Match
• If-Range
• If-Unmodified-Since
• Max-Forwards
• Proxy-Authorization
• RangeReferer
• TE
• User-Agent

下面分别来介绍一下

Accept

HTTP 请求标头会告知客户端可以接收的 MIME 类型是什么

那么什么是 MIME 类型呢？在回答这个问题前你应该先了解一下什么是 MIME

MIME: MIME (Multipurpose Internet Mail Extensions) 是描述消息内容类型的因特网标准。MIME 消息能包含文本、图像、音频、视频以及其余应用程序专用的数据。

也就是说，MIME 类型其实就是一系列消息内容类型的集合。那么 MIME 类型都有哪些呢？

文本文件： text/html、text/plain、text/css、application/xhtml+xml、application/xml

图片文件： image/jpeg、image/gif、image/png

视频文件： video/mpeg、video/quicktime

应用程序二进制文件： application/octet-stream、application/zip

好比，若是浏览器不支持 PNG 图片的显示，那 Accept 就不指定image/png，而指定可处理的 image/gif 和 image/jpeg 等图片类型。

通常 MIME 类型也会和 q 这个属性一块儿使用，q 是什么？q 表示的是权重，来看一个例子

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

这是什么意思呢？若想要给显示的媒体类型增长优先级，则使用 q= 来额外表示权重值，没有显示权重的时候默认值是1.0 ，我给你列个表格你就明白了

q	MIME
1.0	text/html
1.0	application/xhtml+xml
0.9	application/xml
0.8	/

也就是说，这是一个放置顺序，权重高的在前，低的在后，application/xml;q=0.9 是不可分割的总体。

Accept-Charset

Accept-Charset 表示客户端可以接受的字符编码。Accept-Charset 也是属于内容协商的一部分，它和

Accept 同样，也能够用 q 来表示字符集，用逗号进行分割，例如

Accept-Charset: iso-8859-1
Accept-Charset: utf-8, iso-8859-1;q=0.5
Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1

事实上，不少以 Accept-* 开头的标头，都是属于内容协商的范畴，关于内容协商咱们下面会说。

Accept-Encoding

表示 HTTP 标头会标明客户端但愿服务端返回的内容编码，这一般是一种压缩算法。Accept-Encoding 也是属于内容协商 的一部分，使用并经过客户端选择 Content-Encoding 内容进行返回。

即便客户端和服务器都可以支持相同的压缩算法，服务器也可能选择不压缩并返回，这种状况多是因为这两种状况形成的:

• 要发送的数据已经被压缩了一次，第二次压缩并不会致使发送的数据更小
• 服务器过载，没法承受压缩带来的性能开销，一般，若是服务器使用 CPU 超过 80% ，Microsoft 则建议不要使用压缩

下面是 Accept-Encoding 的使用方式

Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

上面的几种表述方式就已经把 Accept-Encoding 的属性列全了

• gzip: 由文件压缩程序 gzip 生成的编码格式，使用 Lempel-Ziv编码（LZ77）和32位CRC的压缩格式，感兴趣的同窗能够读一下 （https://en.wikipedia.org/wiki...）
• compress: 使用Lempel-Ziv-Welch（LZW）算法的压缩格式，有兴趣的同窗能够读 （https://en.wikipedia.org/wiki...）
• deflate: 使用 zlib 结构和 deflate 压缩算法的压缩格式，参考 （https://en.wikipedia.org/wiki...） 和 （https://en.wikipedia.org/wiki...）
• br: 使用 Brotli 算法的压缩格式，参考 （https://en.wikipedia.org/wiki...）
• 不执行压缩或不会变化的默认编码格式
• * : 匹配标头中未列出的任何内容编码，若是没有列出 Accept-Encoding ，这就是默认值，并不意味着支

  持任何算法，只是表示没有偏好

• ;q= 采用权重 q 值来表示相对优先级，这点与首部字段 Accept 相同。

Accept-Language

Accept-Language 请求表示客户端须要服务端返回的语言类型，Accept-Language 也属于内容协商的范畴。服务端经过 Content-Language 进行响应，和 Accept 首部字段同样，按权重值 q 来表示相对优先级。例如

Accept-Language: de
Accept-Language: de-CH
Accept-Language: en-US,en;q=0.5

Authorization

HTTP Authorization 请求头用于向服务器认证用户代理的凭据，一般用在服务器以401未经受权状态和WWW-Authenticate标头响应以后，啥意思呢？你不明白的话我画张图给你看

请求标头 Authorization 是用来告知服务器，用户的认证信息，服务器在只有收到认证后才会返回给客户端 200 OK 的响应，若是没有认证信息，则会返回 401 并告知客户端须要认证信息。详细关于 Authorization 的信息，后面也会详细解释

Expect

Expect HTTP 请求标头指示服务器须要知足的指望才能正确处理请求。若是服务器没有办法完成客服端所指望完成的事情而且服务端存在错误的话，会返回 417 Expectation Failed 。HTTP 1.1 只规定了100-continue 。

• 若是服务器能正常完成客户端所指望的事情，会返回 100
• 若是不能知足指望或返回任何其余4xx 的状态码，会返回 417

例如

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

From

From 请求头用来告知服务器使用用户代理的电子邮件地址。一般状况下，其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式。咱们在使用代理的状况下，应尽量包含 From 首部字段。例如

From: webmaster@example.org

你不该该将 From 用在访问控制或者身份验证中

Host

Host 请求头指明了服务器的域名（对于虚拟主机来讲），以及（可选的）服务器监听的TCP端口号。若是没有给定端口号，会自动使用被请求服务的默认端口（好比请求一个 HTTP 的 URL 会自动使用80做为端口）。

Host: developer.mozilla.org

Host 首部字段在 HTTP/1.1 规范内是惟一一个必须被包含在请求内的首部字段。

If-Match

If-Match 后面能够跟一大堆属性，形式像 If-Match 这种的请求头称为条件请求，服务器接收到条件请求后，须要断定条件请求是否知足，只有条件请求为真，才会执行条件请求

相似的还有 If-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since

对于 GET 和 POST 方法，服务器仅在与列出的 ETag（响应标头） 之一匹配时才返回请求的资源。这里又多了一个新词 ETag，咱们稍后再说 ETag 的用法。对于像是 PUT 和其余非安全的方法，在这种状况下，它仅仅将上传资源。

下面是两种常见的案例

• 对于 GET 和 POST 方法，会结合使用 Range 标头，它能够确保新发送请求的范围与上一个请求的资源相同，若是不匹配的话，会返回 416 响应。
• 对于其余方法，特别是 PUT 方法，If-Match 能够防止丢失更新，服务器会比对 If-Match 的字段值和资源的 ETag 值，仅当二者一致时，才会执行请求。反之，则返回状态码 412 Precondition Failed 的响应。例如

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
If-Match: *

If-Modified-Since

If-Modified-Since 是 HTTP 条件请求的一部分，只有在给定日期以后，服务端修改了请求所须要的资源，才会返回 200 OK 的响应。若是在给定日期以后，服务端没有修改内容，响应会返回 304 而且不带任何响应体。If-Modified-Since 只能使用 GET 和 HEAD 请求。

If-Modified-Since 与 If-None-Match 结合使用时，它将被忽略，除非服务器不支持 If-None-Match。通常表示以下

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

注意：这是格林威治标准时间。 HTTP 日期始终以格林尼治标准时间表示，而不是本地时间。

If-None-Match

条件请求，它与 If-Match 的做用相反，仅当 If-None-Match 的字段值与 ETag 值不一致时，可处理该请求。对于GET 和 HEAD ，仅当服务器没有与给定资源匹配的 ETag 时，服务器将返回 200 做为响应。对于其余方法，仅当最终现有资源的 ETag 与列出的任何值都不匹配时，才会处理请求。

当 GET 和 POST 发送的 If-None-Match与 ETag 匹配时，服务器会返回 304。

If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
If-None-Match: W/"67ab43", "54ed21", "7892dd"
If-None-Match: *

有同窗可能会好奇 W/ 是什么意思，这实际上是 ETag 的弱匹配，关于 ETag 咱们会在响应标头中详细讲述。

If-Range

If-Range 也是条件请求，若是知足条件（If-Range 的值和 ETag 值或者更新的日期时间一致），则会发出范围请求，不然将会返回所有资源。它的通常表示以下

If-Range: Wed, 21 Oct 2015 07:28:00 GMT

If-Unmodified-Since

If-Unmodified-Since HTTP 请求标头也是一个条件请求，服务器只有在给定日期以后没有对其进行修改时，服务器才返回请求资源。若是在指定日期时间后发生了更新，则以状态码 412 Precondition Failed 做为响应返回。

If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT

Max-Forwards

MDN 把这个标头置灰了，因此下面内容取自《图解 HTTP》

Max-Forwards 通常用于 TRACE 和 OPTION 方法，发送包含 Max-Forwards 的首部字段时，每通过一个服务器，Max-Forwards 的值就会 -1，直到 Max-Forwards 为0时返回。Max-Forwards 是一个十进制的整数值。

Max-Forwards: 10

能够灵活使用首部字段 Max-Forwards，针对以上问题产生的缘由展开调查。因为当 Max-Forwards 字段值为 0 时，服务器就会当即返回响应，由此咱们至少能够对以那台服务器为终点的传输路径的通讯情况有所把握。

Proxy-Authorization

Proxy-Authorization 是属于请求与认证的范畴，咱们在上面提到一个认证的 HTTP 标头是 Authorization，不一样于 Authorization 发生在客户端 - 服务器之间；Proxy-Authorization 发生在代理服务器和客户端之间。它表示接收到从代理服务器发来的认证时，客户端会发送包含首部字段 Proxy-Authorization 的请求，以告知服务器认证所须要的信息。

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

Range

Range HTTP 请求标头指示服务器应返回文档指定部分的资源，能够一次请求一个 Range 来返回多个部分，服务器会将这些资源返回各个文档中。若是服务器成功返回，那么将返回 206 响应；若是 Range 范围无效，服务器返回416 Range Not Satisfiable错误；服务器还能够忽略 Range 标头，而且返回 200 做为响应。

Range: bytes=200-1000, 2000-6576, 19000-

Referer

HTTP Referer 属性是请求标头的一部分，当浏览器向 web 服务器发送请求的时候，通常会带上 Referer，告诉服务器该网页是从哪一个页面连接过来的，服务器所以能够得到一些信息用于处理。

Referer: https://developer.mozilla.org/testpage.html

TE

首部字段 TE 会告知服务器客户端可以处理响应的传输编码方式及相对优先级。它和首部字段 Accept-Encoding 的功能很相像，可是用于传输编码。

TE: gzip, deflate;q=0.5

首部字段 TE 除指定传输编码以外，还能够指定伴随 trailer 字段的分块传输编码的方式。应用后者时，只需把 trailers 赋值给该字段值。

TE: trailers, deflate;q=0.5

User-Agent

首部字段 User-Agent 会将建立请求的浏览器和用户代理名称等信息传达给服务器。

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0

响应标头

刚刚咱们的着重点一直放在客户端请求，如今咱们把关注点转换一下放在服务器上。响应首部字段是由服务器发送给客户端响应中所包含的字段，用于补充相应信息等，这部分标头也是很是多，咱们先一块儿来看一下

• Accept-Ranges
• Age
• ETag
• Location
• Proxy-Authenticate
• Retry-After
• Server
• Vary
• www-Authenticate

Accept-Ranges

Accept-Ranges HTTP 响应标头，这个标头有两个值

• 当服务器可以处理客户端发送过来的请求时，使用bytes 来指定
• 当服务器不能处理客户端发来的请求时，使用 none 来指定

Accept-Ranges: bytes
Accept-Ranges: none

Age

Age HTTP 响应标头告诉客户端源服务器在多久以前建立了响应，它的单位为秒，Age 标头一般接近于0，若是是0则多是从源服务器获取的，若是不是表示多是由代理服务器建立，那么 Age 的值表示的是缓存后的响应再次发起认证到认证完成的时间值。代理建立响应时必须加上首部字段 Age。通常表示以下

Age: 24

ETag

ETag 对于条件请求来讲真是过重要了。由于条件请求就是根据 ETag 的值进行匹配的，下面咱们就来详细了解一下。

ETag 响应头是特定版本的标识，它可以使缓存变得更高效并可以节省带宽，由于若是缓存内容未发生变动，Web 服务器则不须要从新发送完整的响应。除此以外，ETag 可以防止资源同时更新互相覆盖。

若是给定 URL 上的资源发生变动，必须生成一个新的 ETag 值，经过比较它们能够肯定资源的两个表示形式是否相同。

ETag 值有两种，一种是强 ETag，一种是弱 ETag；

• 强 ETag 值，不管实体发生多么细微的变化都会改变其值，通常的表示以下

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

• 弱 ETag 值，弱 ETag 值只用于提示资源是否相同。只有资源发生了根本改变，产生差别时才会改变 ETag 值。这时，会在字段值最开始处附加 W/。

ETag: W/"0815"

Location

Location 响应标头表示 URL 须要重定向页面，它仅仅与 3xx(重定向) 或 201(已建立) 状态响应一块儿使用。下面是一个页面重定向的过程

使用首部字段 Location 能够将响应接受方引导至某个与请求 URI 位置不一样的资源。

Location 和 content-Location 是不同的：Location 表示目标的重定向（或新建立资源的 URL）。然而 Content-Location 表示发生内容协商时用于访问资源的直接 URL，而无须进一步协商。Location 是与响应相关联的标头，而 Content-Location 与返回的实体相关联。

Location: /index.html

Proxy-Authenticate

HTTP 响应标头 Proxy-Authenticate 会定义认证方法，应该使用身份验证方法来访问代理服务器后面的资源即客户端。

它与 HTTP 客户端和服务端之间的访问认证行为类似，不一样之处在于 Proxy-Authenticate 的认证双方是客户端与代理之间。它的通常表示形式以下

Proxy-Authenticate: Basic
Proxy-Authenticate: Basic realm="Access to the internal site"

Retry-After

HTTP 响应标头 Retry-After 告知客户端须要在多久以后从新发送请求，使用此标头主要有以下三种状况

• 当发送 503(服务不可用) 响应时，这表示该服务预计没法使用多长时间。
• 当发送 429(太多请求)响应时，这表示发出新请求以前要等待多长时间。
• 当发送重定向的响应像是 301(永久移动)，这表示在发出重定向请求以前要求用户客户端等待的最短期。

字段值能够指定为具体的日期时间，也能够是建立响应后所持续的秒数，例如

Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120

Server

服务器标头包含有关原始服务器用来处理请求的软件的信息。

应该避免使用过于冗长和详细的 Server 值，由于它们可能会泄露内部实施细节，这可能会使攻击者容易地发现并利用已知的安全漏洞。例以下面这种写法

Server: Apache/2.4.1 (Unix)

Vary

Vary HTTP 响应标头肯定如何匹配请求标头，以决定是否可使用缓存的响应，而不是从原始服务器请求一个新的响应。

Vary: User-Agent

www-Authenticate

HTTP WWW-Authenticate 响应标头定义了应用于得到对资源的访问权限的身份验证方法。WWW-Authenticate标头与401未经受权的响应一块儿发送。它的通常表示形式以下

WWW-Authenticate: Basic
WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"

Access-Control-Allow-Origin

一个返回的 HTTP 标头可能会具备 Access-Control-Allow-Origin ，Access-Control-Allow-Origin 指定一个来源，它告诉浏览器容许该来源进行资源访问。 不然-对于没有凭据的请求 *通配符，告诉浏览器容许任何源访问资源。例如，要容许源 https://mozilla.org 的代码访问资源，能够指定：

Access-Control-Allow-Origin: https://mozilla.org
Vary: Origin

若是服务器指定单个来源而不是 * 通配符的话 ，则服务器还应在 Vary 响应标头中包含 Origin ，以向客户端指示 服务器响应将根据原始请求标头的值而有所不一样。

实体标头

实体标头用于HTTP请求和响应中，例如 Content-Length，Content-Language，Content-Encoding 的标头是实体标头。实体标头不局限于请求标头或者响应标头，下面例子中，Content-Length 是一个实体标头，可是却出如今了请求报文中

POST /myform.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Content-Length: 128

下面就来讲一下实体标头都包含哪些

• Allow
• Content-Encoding
• Content-Language
• Content-Length
• Content-Location
• Content-MD5
• Content-Range
• Content-Type
• Expires
• Last-Modified

下面来分开说一下

Allow

HTTP 实体标头 Allow 列出了资源支持的方法集合。若是服务器响应405 Method Not Allowed状态码以指示可使用哪些请求方法，则必须发送此标头。例如

Allow: GET, POST, HEAD

这段代码表示服务器容许支持 GET 、POST 和 HEAD 方法。当服务器接收到不支持的 HTTP 方法时，会以状态码 405 Method Not Allowed 做为响应返回。

Content-Encoding

咱们上面讲过 Accept-Encoding 是客户端但愿服务端返回的内容编码，可是实际上服务端返回给客户端的内容编码其实是经过 Content-Encoding 返回的。内容编码是指在不丢失实体信息的前提下所进行的压缩。主要也是四种，和 Accept-Encoding 相同，它们是 gzip、compress、deflate、identity。下面是一组请求/响应内容压缩编码

Accept-Encoding: gzip, deflate
Content-Encoding: gzip

Content-Language

首部字段 Content-Language 会告知客户端，服务器使用的天然语言是什么，它与 Accept-Language 相对，下面是一组请求/响应使用的语言类型

Content-Language: de-DE, en-CA

Content-Length

Content-Length 的实体标头指服务器发送给客户端的实际主体大小，以字节为单位。

Content-Length: 3000

如上，服务器返回给客户端的主体大小是 3000 字节。

Content-Location

Content-Location 可不是对应 Accept-Location，由于没有这个标头哈哈哈哈。实际上 Content-Location 对应的是 Location。

Location 和 Content-Location 是不同的，Location 表示重定向的 URL，而 Content-Location 表示用于访问资源的直接 URL，之后无需进行进一步的内容协商。Location 是与响应关联的标头，而 Content-Location 是与返回的数据相关联的标头，若是你很差理解，看一下下面的表格

Request header	Response header
Accept: application/json, text/json	Content-Location: /documents/foo.json
Accept: application/xml, text/xml	Content-Location: /documents/foo.xml
Accept: text/plain, text/*	Content-Location: /documents/foo.txt

Content-MD5

客户端会对接收的报文主体执行相同的 MD5 算法，而后与首部字段 Content-MD5 的字段进行比较。

Content-MD5: e10adc3949ba59abbe56e057f20f883e

首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在于检查报文主体在传输过程当中是否保持完整，有无被修改的状况，以及确认传输到达。

Content-Range

HTTP 的 Content-Range 响应标头是针对范围请求而设定的，返回响应时使用首部字段 Content-Range，可以告知客户端响应实体的哪部分是符合客户端请求的，字段以字节为单位。它的通常表示以下

Content-Range: bytes 200-1000/67589

上段代码表示从全部 67589 个字节中返回 200-1000 个字节的内容

Content-Type

HTTP 响应标头 Content-Type 说明了实体内对象的媒体类型，和首部字段 Accept 同样使用，表示服务器可以响应的媒体类型。

Expires

HTTP Expires 实体标头包含 日期/时间，在该日期/时间以后，响应被认为过时；在响应时间以内被认为有效。特殊的值好比0表示过去的日期，表示资源已过时。

Expires: Wed, 21 Oct 2015 07:28:00 GMT

源服务器会将资源失效的日期或时间发送给客户端，缓存服务器在接受到 Expires 的响应后，会判断是否把缓存返回给客户端。

源服务器不但愿缓存服务器对资源缓存时，最好在 Expires 字段内写入与首部字段 Date 相同的时间值。可是，当首部字段 Cache-Control 有指定 max-age 指令时，比起首部字段 Expires，会优先处理 max-age 指令。

Last-Modified

实体字段 Last-Modified 指明资源的最后修改时间，它用做验证器来肯定接收或存储的资源是否相同。它的做用不如 ETag 那么准确，它能够做为一种后备机制，包含 If-Modified-Since 或 If-Unmodified-Since 标头的条件请求将使用此字段。它的通常表示以下

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

总结

本篇文章主要介绍了 HTTP 四种标头的基本概念，可是并无涵盖所有，毕竟 HTTP 标头内容确实太多了，以上介绍的基本都是日常工做中经常使用的一些概念，下一篇文章预告 HTTP 的黑科技

文章参考：

https://developer.mozilla.org...

http://www.tcpipguide.com/fre...

http://www.tcpipguide.com/fre...

https://developer.mozilla.org...

《图解 HTTP》

https://www.w3.org/Protocols/...

https://blog.csdn.net/qq_2940...

https://en.wikipedia.org/wiki...