content-encoding: deflate的麻烦事
访问一个URL获取一个弹幕资源,在浏览器里访问,显示的是好好的:
是个XML文件,内容可理解。
在firefox里也正常:
然后content-encoding里也说了,是deflate,也就是内容有压缩后传输的。
从传输80多k,实际大小200多k的相关信息,也可以看的出来。
因为以前接触过gzip压缩的,所以当我把这个资源用wget获取下来之后,
可以看到获取到的内容是80多k。用file看一下,认为类型是data
这个就不太妙,用gunzip打不开:not in gzip format
unpigz也不行:unrecognized format
这就让人郁闷了,怎么办呢?不好办,挺折腾人的
问题整理一下,应该还是比较清楚的:那就是传输的内容保存下来了,浏览器可以自动解压,但手工没法解压
继续之前插个广告,学习一下transfer-encoding:chunked
HTTP 1.1引入分块传输编码提供了以下几点好处:
1. HTTP分块传输编码允许服务器为动态生成的内容维持HTTP持久链接。通常,持久链接需要服务器在开始发送消息体前发送Content-Length消息头字段,但是对于动态生成的内容来说,在内容创建完之前是不可知的。[1]
2. 分块传输编码允许服务器在最后发送消息头字段。对于那些头字段值在内容被生成之前无法知道的情形非常重要,例如消息的内容要使用散列进行签名,散列的结果通过HTTP消息头字段进行传输。没有分块传输编码时,服务器必须缓冲内容直到完成后计算头字段的值并在发送内容前发送这些头字段的值。
3. HTTP服务器有时使用压缩 (gzip或deflate)以缩短传输花费的时间。分块传输编码可以用来分隔压缩对象的多个部分。在这种情况下,块不是分别压缩的,而是整个负载进行压缩,压缩的输出使用本文描述的方案进行分块传输。在压缩的情形中,分块编码有利于一边进行压缩一边发送数据,而不是先完成压缩过程以得知压缩后数据的大小。
————————————————
版权声明:本文为CSDN博主「公众号:流花鬼」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_32331073/article/details/82148409
好了广告结束,欢迎回来
另外也试了git bash里带的openssl zlib命令,也不行:
真的烦死了,用python试试:
直到我找到了一个网上的说明:how-can-i-decompress-a-gzip-stream-with-zlib
python
- RFC 1950 (
zlib
compressed format) - RFC 1951 (
deflate
compressed format) - RFC 1952 (
gzip
compressed format)
The python zlib
module will support these as well.
choosing windowBits
But zlib
can decompress all those formats:
- to (de-)compress
deflate
format, usewbits = -zlib.MAX_WBITS
- to (de-)compress
zlib
format, usewbits = zlib.MAX_WBITS
- to (de-)compress
gzip
format, usewbits = zlib.MAX_WBITS | 16
See documentation in http://www.zlib.net/manual.html#Advanced (section inflateInit2
)
于是改一改就好了:
吁~折腾的气闷,闷的左肋疼,
搞定了,收工~
- 点赞
- 收藏
- 关注作者
评论(0)