1

我在使用 okhttp 时遇到了这个错误。请帮我分析错误原因并给我解决方案

 @Override public long read(Buffer sink, long byteCount) throws IOException { 
if (byteCount < 0) throw new IllegalArgumentException("byteCount < 0: " + byteCount); 
if (byteCount == 0) return 0; 

// If we haven't consumed the header, we must consume it before anything else. 
if (section == SECTION_HEADER) { 
  consumeHeader(); 
  section = SECTION_BODY; 
} 

// Attempt to read at least a byte of the body. If we do, we're done. 
if (section == SECTION_BODY) { 
  long offset = sink.size; 
  long result = inflaterSource.read(sink, byteCount); 
  if (result != -1) { 
    updateCrc(sink, offset, result); 
    return result; 
  } 
  section = SECTION_TRAILER; 
} 

// The body is exhausted; time to read the trailer. We always consume the 
// trailer before returning a -1 exhausted result; that way if you read to 
// the end of a GzipSource you guarantee that the CRC has been checked. 
if (section == SECTION_TRAILER) { 
  consumeTrailer(); 
  section = SECTION_DONE; 

  // Gzip streams self-terminate: they return -1 before their underlying 
  // source returns -1. Here we attempt to force the underlying stream to 
  // return -1 which may trigger it to release its resources. If it doesn't 
  // return -1, then our Gzip data finished prematurely! 
 if (!source.exhausted()) { 
    throw new IOException("gzip finished without exhausting source"); 
  }
} 

return -1; 

}

在此处输入图像描述

在此处输入图像描述CH.png

throw new IOException("gzip 完成但没有耗尽源");

4

1 回答 1

0

杰克沃顿比尔博西奥利

好的。这个可以关闭。它与改造/OkHttp 无关。

事实上,问题似乎在于服务器代码(而不是 Apache)总是发送一个 Content-Length 标头,即使在使用分块编码的情况下也是如此。

https://github.com/square/retrofit/issues/1170

于 2017-07-07T03:09:19.837 回答