Question

我在使用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;

}

enter image description here

enter image description here CH.png

抛出新的IOException（＆＃34; gzip完成而不会耗尽资源＆＃34;）;

Answer 1

JakeWharton BillBosiolis

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

事实上，似乎问题是服务器代码（不是Apache）总是发回Content-Length头，即使在使用分块编码的情况下也是如此。

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

一个例外：gzip完成没有耗尽源，关于Okhttp，okio

1 个答案: