2021.10.20

1. 问题澄清：
2. Plugtest IDMS对接版本准备；
3. 蓝牙手咪适配问题配合定位；
4. Mcdata http彩信上传，接口方案DT联调；
5. 河北联创项目联调；

OkHttp3错误异常: java.net.ProtocolException: unexpected end of stream 源码分析

在项目中出现这个错误的原因肯定是跟服务器返回值的响应头中Content-Length的长度有关，为了验证这个问题，我将报错接口的返数据通过抓包出来分析了一下：

可以看到响应头中返回的Content-Length的大小是1004，charset是UTF-8，那么正常情况下响应正文也就是body中的字符串按照UTF-8编码的字节长度应该等于Content-Length的大小1004，于是，我写了一下代码把正文按照UTF-8编码的字节长度打印出来，打印代码很简单，就一句话：

TQLog.e(TAG, "length = " + str.getBytes(StandardCharsets.UTF_8).length);

1

果然，打印出的长度值为length = 992，居然跟响应头中的Content-Length的值不一样！这就有问题了啊，按照OkHttp中Http1Codec类报错的方法的逻辑，source.read(sink, Math.min(bytesRemaining, byteCount))这里第二个参数，将会在1004和8k之间取最小值为1004，也就是说会直接从body的输入源对象source读取1004个字节的长度，然而实际响应正文返回字符串的长度不足1004只有992。最终source必然会不够读取返回-1，从而报错。

当然实际debug发现过程跟这个有点出入，但是差别不大，实际当bytesRemaining比byteCount小时，source.read读取时不是一次性把source读完的，这主要是有个方法导致的，但是总的bytesRemaining跟Content-Length是一致的。