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
是不可分割的整体。