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/LZ77_and_LZ78#LZ77）compress: 使用Lempel-Ziv-Welch（LZW）算法的压缩格式，有兴趣的同学可以读 （https://en.wikipedia.org/wiki/LZW）deflate: 使用 zlib 结构和 deflate 压缩算法的压缩格式，参考 （https://en.wikipedia.org/wiki/Zlib） 和 （https://en.wikipedia.org/wiki/DEFLATE）br: 使用 Brotli 算法的压缩格式，参考 （https://en.wikipedia.org/wiki/Brotli）- 不执行压缩或不会变化的默认编码格式
*: 匹配标头中未列出的任何内容编码，如果没有列出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
