一次Http请求的Debug记
最近遇到http请求一个较大的json时，返回被截断的问题. json规模，字符数200k+，大小300-500KB.这里记录下解决思路和过程.
现象：
| UA | 截断否 | accept-encoding |
|---|---|---|
| Chrome,FireFox | 否 | gzip, deflate,compress |
| python request lib | 否 | gzip, deflate |
| Java commons-httpclient | 是 | None |
初步定位：
- java client维度
- http 协议参数维度
- 服务端实现配置维度（未知，第三方服务）
方法论：
- 仔细对比java , python ,web browser三个client，在这三个维度上的差异.
- 抓包，从溯源而上排查Http、TCP的请求整个过程.
结论
问题较常见，也比较容易就定位到了问题：：服务器close的没有发完的chunk数据包。具体服务端如何限制的不得而知（估计是nginx的缺省配置）。改进是:客户端声明接受gzip,deflate的压缩编码数据，降低数据传输量。一种治标不治本的解决方案。
对于大数据返回，首先应该考虑压缩。服务器需要开启gzip，deflate等压缩特性。比如nginx 会配置gzip 压缩，gzip_buffer等参数
客户端也应采用对应的压缩解压实现。
本例中，java:apache.common.httpclient 3.1 这个是默认不支持解压的，在http头部不会加入支持压缩编码的参数(accept-encoding), 而现代浏览器，其他较新的软件包都会默认支持这个功能。
因此，升级下java httpclient 包就圆满解决了
升华
关于http常有头部参数含义，整理一下，详细可参看RFC2616