http实体数据的请求响应

客户端像服务端请求数据，在客户端浏览器进行渲染，需要知道文件的格式，需要知道服务端返回到客户端的文本格式，否则渲染会出错。因此http需要标记一下body的类型，因此请求响应支持MIME 规范。

http常用的几个类别：MIME type

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

Encodeing type：

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

因此http定义了Accept和Content两个字体头字段。用于客户端和服务端的内容指定

Accept：代表客户端在请求头中指明的我需要什么数据，可以处理什么数据。（也就是客户端可以理解的数据）

代表我可以理解这四种格式数据。

Content：代表服务端给客户端返回的数据，告诉客户端我返回的是什么格式的数据。（注：Content不止可以在服务端返回使用，在客户端给服务端发送数据的时候也可以指定。）

Conten-type：也就是说告诉用户我提供的数据真实类型。

Accept-Encoding：代表客户端支持的压缩格式。Content-Encoding：代表真实使用的压缩格式。

如果头里不存在，代表不支持压缩格式。如果响应报文中没有，代表响应文本没有压缩。

解决了压缩，但是世界各国有不同的语言和不同的编码格式，因此引入Accept-Language和Content-Languahe来指定需要的语言格式。

引入Accept-Charset和Content-type解决编码问题

浏览器通常不会发送Accept-Charset和Content-type因为使用Language就可以推断出来字符：

 

在 HTTP 协议里用 Accept、Accept-Encoding、Accept-Language 等请求头字段进行内容协商的时候，还可以用一种特殊的“q”参数表示权重来设定优先级，这里的“q”是“quality factor”的意思。

权重的最大值是 1，最小值是 0.01，默认值是 1，如果值是 0 就表示拒绝。具体的形式是在数据类型或语言代码后面加一个“;”，然后是“q=value”。

这里要提醒的是“;”的用法，在大多数编程语言里“;”的断句语气要强于“,”，而在 HTTP 的内容协商里却恰好反了过来，“;”的意义是小于“,”的。

解说：它表示浏览器最希望使用的是 HTML 文件，权重是 1，其次是 XML 文件，权重是 0.9，最后是任意数据类型，权重是 0.8。服务器收到请求头后，就会计算权重，再根据自己的实际情况优先输出 HTML 或者 XML。

请求和响应对应头：