Accept-Encoding和Content-Encoding
Accept-Encoding和Content-Encoding是HTTP中用来对采用何种压缩格式传输正文进行协定的一对header。工作原理如下：
- 浏览器发送请求，通过Accept-Encoding带上自己支持的内容编码格式列表
- 服务端从中挑选一个用来对正文进行编码，并通过Content-Encoding响应头指明响应编码格式。
- 浏览器拿到响应正文后，根据Content-Encoding进行解压缩。服务端若响应未压缩的正文，则不允许返回Content-Encoding。
压缩类型：
- gzip：表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及32位CRC校验的编码方式
- Compress：采用Lempel-Ziv-Welch (LZW) 压缩算法。
- deflate：表示采用 zlib 结构 (在 RFC 1950 中规定)，和 deflate 压缩算法(在 RFC 1951 中规定)。
- identity：用于指代自身（未经过压缩和修改）。除非特别指明，这个标记始终可以被接受。
- Br：表示采用Brotli 算法的编码方式。
内容编码：
- 内容编码针对的只是传输正文。HTTP/1中，header始终是以ASCII文本传输，没有经过任何压缩；HTTP/2中引入header压缩技术。
传输编码Transfer-Encoding
- 用于表示节点之间传输message的编码方式。最典型是分块传输（chunked）
- 是一个响应header
Transfer-Encoding支持类型：
- chunked
- compress
- deflate
- gzip
- identit
- 多个类型可以共存
Gzip+Curl例子：
echo "content=Web%20%E5%AE%89%E5%85%A8%E6%98%AF%E4%B8%80%E9%A1%B9%E7%B3%BB%E7%BB%9F%E5%B7%A5%E7%A8%8B%EF%BC%8C%E4%BB%BB%E4%BD%95%E7%BB%86%E5%BE%AE%E7%96%8F%E5%BF%BD%E9%83%BD%E5%8F%AF%E8%83%BD%E5%AF%BC%E8%87%B4%E6%95%B4%E4%B8%AA%E5%AE%89%E5%85%A8%E5%A0%A1%E5%9E%92%E5%9C%9F%E5%B4%A9%E7%93%A6%E8%A7%A3%E3%80%82" | gzip -c > data.txt.gz
curl -v --data-binary @data.txt.gz -H\'Content-Type: application/x-www-form-urlencoded; charset=UTF-8\' -H\'Content-Encoding: gzip\' -X POST https://qgy18.com/node/
Transfer-Encoding与Content-Encoding的区别：
- Transfer-Encoding只是在传输过程中才有的，并发请求URL对应实体的本身特性。
- Transfer-Encoding是一个"跳到跳"的header，而Content-Encoding是"端到端"的header。
Content-type
Content-type是HTTP的实体首部，用于说明请求或者返回的消息主体是用何种方式编码（即资源的MIME类型）。在请求、响应header中均存在。
示例如下：
Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
参数一般包含：
- media-type：资源或者数据的MIME type
- charset：字符编码标准
- boundary：多于多部实体，boundary是必需的。其包括一组1到70个字符，用于封装消息的多个部分的边界。
Media-type常用类型：
-
application/x-www-form-urlencoded
- form表单或者提交的数据按照key1=value1&key2=value2方式进行编码，key、value均进行了urlencode
-
multipart/form-data
- 常见的POST数据提交的方式，使用form进行文件上传的时候，必须让form的enctype为这个。
-
application/json
- 消息主体是序列化后的json字符串。
-
text/html
- 是一种用HTTP作为传输协议，XML作为编码方式的远程调用规范。