就是 POST 请求是否也可以采用 gzip 压缩，然后服务器自行解压？
This topic created in 3731 days ago, the information mentioned may be changed or developed.
 |
1
一般服务器不支持吧？只能自行实现?
|
 |
2
为什么不可以呢，以及为什么不试一下呢
|
1 |
3
|
 |
4
post 数据只是做 url 编码， 并不会 gzip, 而且上传数据(multipart/form-data)连 url 编码都不会做.
如果 post 的数据不大， 或者上传的是图片或者压缩文件一类， 这类情况 gzip 不仅不会压小， 还可能会变大, 客户端是不可信任的， 理论上可以用简单的结构构造出一个压缩后极小但是解压后极大的数据来爆服务器内存. |
|
5
"post 数据只是做 url 编码， 并不会 gzip, 而且上传数据(multipart/form-data)连 url 编码都不会做. "
=> "post 数据只是做 url 编码， 并不会 base64, 而且上传数据(multipart/form-data)连 url 编码都不会做. " |
 |
6
post 数据可以压缩的
|
|
7
关键字：
Content-Encoding: gzip |
 |
8
传统上某些 8-bit byte 会被砍掉首位所以只能传输 7-bit byte. url encode 和 base64 都能完成这个变换. 但是指定 content-type 为一种私有或者二进制类型很不好看, 推荐用 multipart 上传的方式, 稍微浪费一个头的空间还不算太离谱.
|
 |
9
|
|
10
Demo 地址： https://qgy18.com/request-compress/
|
 |
11
@Zzzzzzzzz 按照最后这样逻辑的话，服务器也可以用简单的结构构造出一个压缩后极小但是解压后极大的数据来爆访问者内存？
|
 |
12
如果服务端和客户端都是你做的，那你非要这么做当然可以，但是，一般的情况下服务端不是你控制的，
你都不知道服务端支持不支持 gzip ，就直接传了压缩过的数据过去，让人家怎么处理？ 还有就是 4 楼提到的安全问题，如果服务端接受压缩过的数据，客户端扔一个 zip 炸弹上来，解压出来几十 G ，服务器处理不好的话岂不嗝儿屁 |
 |
15
@aprikyblue 你说的对，有一个反扒技术就是这样。利用 gzip 压缩一个 TB 级别的都是 0 的文件。目前浏览器对这种情况有拦截，不会出大问题。但一般爬虫不考虑这个，直接把磁盘爆掉。
|
|
16
@aprikyblue 有啊， gzip bomb, 但最多让浏览器崩一下， 主要用途倒是像楼上说的，对二三线爬虫有奇效.
|
Select Language