HTTP 内容协商

HTTP 内容协商

HTTP报文的结构是 “header+body” 。body数据在到达后，必须要告诉上层应用这是什么数据，即必须有内容协商(字段)。

对于告知对端所传输的数据类型的功能，早在 HTTP 协议诞生之前就已经有了针对这种问题的解决方案，不过它是用在电子邮件系统里的，让电子邮件可以发送 ASCII 码以外的任意数据，方案的名字叫做“多用途互联网邮件扩展”（Multipurpose Internet Mail Extensions），简称为 MIME。

HTTP 采用MIME type 来标记Body 的数据类型。MIME 把数据分成了八大类，每个大类下再细分出多个子类，形式是“type/subtype”的字符串，巧得很，刚好也符合了 HTTP 明文的特点，所以能够很容易地纳入 HTTP 头字段里。

HTTP中常见的几种类别：

• text：即文本格式的可读数据，我们最熟悉的应该就是 text/html 了，表示超文本文档，此外还有纯文本 text/plain、样式表 text/css 等。
• image：即图像文件，有 image/gif、image/jpeg、image/png 等。
• audio/video：音频和视频数据，例如 audio/mpeg、video/mp4 等。
• application：数据格式不固定，可能是文本也可能是二进制，必须由上层应用程序来解释。常见的有 application/json，application/javascript、application/pdf 等，另外，如果实在是不知道数据是什么类型，就是 application/octet-stream，即不透明的二进制数据。

但仅有 MIME type 还不够，因为 HTTP 在传输时为了节约带宽，有时候还会压缩数据，因此会使用Encoding type， 告诉数据是用的什么编码格式，这样对方才能正确解压缩，还原出原始的数据。

Encoding type 常用的主要有三种：

• gzip：GNU zip 压缩格式，也是互联网上最流行的压缩格式；
• deflate：zlib（deflate）压缩格式，流行程度仅次于 gzip；
• br：一种专门为 HTTP 优化的新压缩算法

数据类型使用的头字段

有了 MIME type 和 Encoding type，无论是浏览器还是服务器就都可以轻松识别出 body 的类型，也就能够正确处理数据了。HTTP 协议为此定义了两个 Accept 请求头字段和两个 Content 实体头字段，用于客户端和服务器进行内容协商。主要有

客户端
Accept: text/html,application/xml,image/webp,image/png
服务器：
Content-Type: text/html
Content-Type: image/png

Accept-Encoding 字段标记的是客户端支持的压缩格式

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

不过这两个字段是可以省略的，如果请求报文里没有 Accept-Encoding 字段，就表示客户端不支持压缩数据；如果响应报文里没有 Content-Encoding 字段，就表示响应数据没有被压缩。

语言类型和编码

对于语言与编码的内容协商，HTTP使用Accept-Language字段标记。

Accept-Language: zh-CN, zh, en

Content-Language: zh-CN

字符集在 HTTP 里使用的请求头字段是 Accept-Charset，但响应头里却没有对应的 Content-Charset，而是在 Content-Type 字段的数据类型后面用“charset=xxx”来表示，即

Accept-Charset: gbk, utf-8
Content-Type: text/html; charset=utf-8

内容协商的质量值

在 HTTP 协议里用 Accept、Accept-Encoding、Accept-Language 等请求头字段进行内容协商的时候，还可以用一种特殊的“q”(quality factor)参数表示权重来设定优先级。权重的最大值是 1，最小值是 0.01，默认值是 1，如果值是 0 就表示拒绝。具体的形式是在数据类型或语言代码后面加一个“;”，然后是“q=value”。例如：

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