今天在开发中遇见一个问题，同样一个请求，okhttp调用时候，报错gzip finished without exhausting source，浏览器和postman确是正常返回结果

    String getsync = OkHttpUtils.builder().url(wfsSearchUrl)
        // .addHeader("Accept-Encoding", "gzip, deflate") #失败
        .addHeader("Accept-Encoding", "identity") #成功
        .addParam("键", "值")
        .addParam("键", "值")
        .get()
        .sync();

问题描述

默认情况下,OkHttpClient默认对请求和返回数据进行"gzip"的自动解压缩的,而发生这个异常的原因是：服务器返回数据的时候，自动将gzip的数据解压了，导致okhttpclient在去解压的时候发现流已经被读完了

解决方案
在请求的header中加入：

.addHeader("Accept-Encoding", "gzip, deflate");

这样okhttpclient就不会对请求和返回数据自动解压缩了，返回的结果是压缩的，看到的一般是一堆乱码，需要自动手动解压缩
可以通过修改header参数为：

.addHeader("Accept-Encoding", "identity")

实现返回结果是正常json效果

相关参考

1. OkHttpUtils封装类
   https://blog.csdn.net/weixin_45203607/article/details/124204137
2. OkHttp3发送http请求在Java中的使用方法
   https://blog.csdn.net/u011109589/article/details/130348387
3. OkHttp抛出异常java.net.ProtocolException: unexpected end of stream
   https://blog.csdn.net/tuzbtla/article/details/127691162
4. okhttp fails with IOException: gzip finished without exhausting source but GZIPInputStream works #3759
   https://github.com/square/okhttp/issues/3759
5. Accept-Encoding
   https://blog.csdn.net/sqzhao/article/details/49499471
6. responseBody.contentLength()； = -1
   https://blog.csdn.net/qq_25066049/article/details/119812511