背景
gzip解压缩在http请求里面经常听到从来没有真正的处理过，今天终于遇到个问题。先描述一下问题，hiproxy是一个代理服务器。在给hiproxy写一个插件的时候，需要拿到所有请求的数据，包括http协议字段和数据部分。重点在数据部分，hiproxy作为一个代理，其实并不关心请求是否是gzip解压缩的。因为解压是浏览器来做，压缩是服务器来做。但是我的数据是在代理的节点去拿到数据。这时候悲剧就来了，怎么去解压数据。
http chunk
http chunk见的比较多。bigpipe应该就算http chunk传输数据的一种。http请求不停的输出chunk数据，直到结束。那第一个问题来了。所有的数据是先拆chunk后gzip，还是先gzip后拆chunk的呢？我猜是第一种，google了一下，说是两种方式都支持！麻痹，我相信了。
查了node的zlib包，发现解压有两种方式。第一种stream流管道解压。另外一种就是直接解压buffer。然后我就在response的data事件回调中开始操作了。拿到chunk一看是buffer，判断一下encodeing，直接调用zlib.upzip解压了，不幸的是抛异常了:Z_DATA_ERROR。这不应该呀，那换种姿势吧，buffer转stream用管道的方式去解压。麻痹，还是不行。这时候开始怀疑人生了。
开始google, 都是一些gz文件解压，或者response用管道解压返回gz数据。终于我开始怀疑第一个问题了，到底是先gzip还是先拆chunk。最后换种姿势吧，data事件里面缓存chunk，chunk用Buffer.concat拼接起来。end事件里面再判断encoding，选择zlib.gunzip解压。窝草，成功了。。。
到底发生了什么事情
查看了一下http协议，写的明明白白，先gzip再拆分。想一下，先拆chunk再gzip好像也没啥问题呀。那为什么这么搞呢？猜测一下，首先，先拆包再gzip的话，势必数据量会变大。gzip也是有数据写入的呀！窝草，又想到一个问题。不是说浏览器解析html是回一个chunk数据就开始解析了吗？我开始怀疑这个说法了。如果没有gzip那我能理解，你浏览器可以提前渲染，但是gzip了你都没办法解压，渲染个屁啊！
