HTTP 协议 服务区发送数据给客户端可以 GZIP 压缩 那么反过来也可以？

一般服务器不支持吧？只能自行实现?

为什么不可以呢，以及为什么不试一下呢

@skydiver 记得 post 文件的时候 都是 base64 编码 base64 会让内容变长好多 我突然很疑惑 为什么不用 gzip 这样的压缩算法呢

我说的场景是基于浏览器的 而不是自己写程序纯传输用 如果纯传输用 自行拓展一下也是毫无疑问的不是么……

老的 HTTP 协议那时候可能没考虑压缩…… 不知道 HTTP2 有没有相关的，毕竟 HTTP2 不是老协议了。

@qgy18 来来来聊聊

post 数据只是做 url 编码， 并不会 gzip, 而且上传数据(multipart/form-data)连 url 编码都不会做.

如果 post 的数据不大， 或者上传的是图片或者压缩文件一类， 这类情况 gzip 不仅不会压小， 还可能会变大,

客户端是不可信任的， 理论上可以用简单的结构构造出一个压缩后极小但是解压后极大的数据来爆服务器内存.

"post 数据只是做 url 编码， 并不会 gzip, 而且上传数据(multipart/form-data)连 url 编码都不会做. "

=>

"post 数据只是做 url 编码， 并不会 base64, 而且上传数据(multipart/form-data)连 url 编码都不会做. "

关键字：
Content-Encoding: gzip

传统上某些 8-bit byte 会被砍掉首位所以只能传输 7-bit byte. url encode 和 base64 都能完成这个变换. 但是指定 content-type 为一种私有或者二进制类型很不好看, 推荐用 multipart 上传的方式, 稍微浪费一个头的空间还不算太离谱.

当然可以！而且我以前就写过相关文章：

https://imququ.com/post/how-to-compress-http-request-body.html
如何压缩 HTTP 请求正文

Demo 地址： https://qgy18.com/request-compress/

@Zzzzzzzzz 按照最后这样逻辑的话，服务器也可以用简单的结构构造出一个压缩后极小但是解压后极大的数据来爆访问者内存？

如果服务端和客户端都是你做的，那你非要这么做当然可以，但是，一般的情况下服务端不是你控制的，
你都不知道服务端支持不支持 gzip ，就直接传了压缩过的数据过去，让人家怎么处理？
还有就是 4 楼提到的安全问题，如果服务端接受压缩过的数据，客户端扔一个 zip 炸弹上来，解压出来几十 G ，服务器处理不好的话岂不嗝儿屁

@fcicq HTTP 没这个传统。砍掉高位的那是传说中的古代 SMTP

@julyclyde 不过想一下在 UTF-8 以前也没啥压缩, 文本内容砍了高位根本没事. FTP 还分 text 和 binary...

@aprikyblue 你说的对，有一个反扒技术就是这样。利用 gzip 压缩一个 TB 级别的都是 0 的文件。目前浏览器对这种情况有拦截，不会出大问题。但一般爬虫不考虑这个，直接把磁盘爆掉。

@aprikyblue 有啊， gzip bomb, 但最多让浏览器崩一下， 主要用途倒是像楼上说的，对二三线爬虫有奇效.