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 ，我给你列个表格你就明白了
也就是说，这是一个放置顺序，权重高的在前，低的在后，application/xml;q=0.9 是不可分割的整体。
