一.问题阐述
最近做项目的时候遇到这么一个问题:
用 原生 Socket 进行 HTTP 请求的时候,添加了请求头
1 | Accept-Encoding: gzip |
这个请求头表示的含义就是:返回的数据中会对响应体进行压缩,响应头不进行压缩(HTTP/1.1版)
如果服务器支持这种格式的压缩,那么返回的数据会如下这种格式
1 | // 响应头不会压缩 |
服务器压缩的方式可能如下
1 | public static byte[] compress(String str, String encoding) { |
正常情况下,如果请求头包含 gzip,响应时这种方式返回,那么在客户端接收到这种压缩的字节流,只有用同样的压缩流进行解压处理就可以得到数据,并且通常响应头都会包含如下的相应头
1 | Content-Encoding: gzip |
这表示返回的响应体是 gzip 格式的,并且字节流长度为 13131
一般情况是这样
但是在这样一种情况,如果返回的数据很大,或者数据量不确定(如一些动态网页),这个时候服务器就会选择对数据进行分段,并用一个16进制的数进行划分,表示一段的长度,如
1 | HTTP/1.1 200 OK |
这就使得响应头包含 gzip 和 chunked 的数据是一段经过分段的压缩流,因此也就不能简单地使用 GZIPInputStream 对数据进行处理
二.解决方法
对返回的字节流进行一个代理处理
1 | public class SegmentInputStream extends InputStream { |
详细的处理可以看 AppStore