search

square / okhttp

Square’s meticulous HTTP client for the JVM, Android, and GraalVM.
https://square.github.io/okhttp/
Apache License 2.0
45.87k stars 9.16k forks source link

java.io.EOFException at okio.RealBufferedSource.require(RealBufferedSource.java:60) when body is empty when 404 error status #3646

Closed Etery13 closed 7 years ago

Etery13 commented 7 years ago

Dear community! Could you please help me with my bug? There is response, request and an exception in logs below. I expect 404 code response but my tests failed because of weird exception. I replaced url and token in logs with dummy values. logs: 

Oct 10, 2017 7:09:47 PM okhttp3.internal.platform.Platform log
INFO: --> GET https://tttp.com/rs/api/uw/uwUrl?adminSystemId=sdkhgskdjg&programId=12345
Oct 10, 2017 7:09:47 PM okhttp3.internal.platform.Platform log
INFO: Cookie: wdp-initial-auth=false; LtpaToken2=ttoken; Path=/; HttpOnly
Oct 10, 2017 7:09:47 PM okhttp3.internal.platform.Platform log
INFO: --> END GET
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: <-- 404 Not Found https://tttp.com/rs/api/uw/uwrUrl?adminSystemId=sdkhgskdjg&programId=12345 (393ms)
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: X-Backside-Transport: FAIL FAIL
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: Connection: Keep-Alive
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: Transfer-Encoding: chunked
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: Cache-Control: no-store, no-cache, must-revalidate
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: Content-Language: en-US
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: Date: Tue, 10 Oct 2017 16:09:47 GMT
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: Expires: Mon, 09 Oct 2017 16:09:48 GMT
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: Pragma: no-cache
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: X-Powered-By: Servlet/3.1
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: X-Vcap-Request-Id: ef703926-b9d0-4e30-78e2-861345450103
Oct 10, 2017 7:09:48 PM okhttp3.internal.platform.Platform log
INFO: X-Global-Transaction-ID: 0344791159dcf0cc375654d1

java.io.EOFException
at okio.RealBufferedSource.require(RealBufferedSource.java:60)
  at okio.GzipSource.consumeHeader(GzipSource.java:114)
  at okio.GzipSource.read(GzipSource.java:73)
  at okio.RealBufferedSource.request(RealBufferedSource.java:67)
  at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.java:240)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
  at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
  at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:185)
  at okhttp3.RealCall.execute(RealCall.java:69)
  at retrofit2.OkHttpCall.execute(OkHttpCall.java:180)
yschimke commented 7 years ago

This isn't a reproducible bug or something that looks like it requires a fix in OkHttp (yet). Can you please post on stackoverflow with a reproducible test case, or at least your client code.

Please include in your stackoverflow post whether it fails the same way, with or without HttpLoggingInterceptor.

shuaimango commented 6 years ago

我也老是出现这个异常 急求解决

yschimke commented 6 years ago

Google Translate: "I also always appear this exception urgently needed to solve"

@shuaimango can you link to your post on stackoverflow?

skristof commented 5 years ago

Hi, This is a bug quite hard to reproduce. It happens when an empty Gzip stream is returned from the server side as response body and HTTPLoggingInterceptor is set to BODY level. It tries to log the body but the okio.GzipSource.consumeHeader requires a 10 bytes Gzip header. The check at okio.RealBufferedSource.require throws an EOFException.

The responseBody.contentLength is -1 in this case. Anyhow a -1 contentLength should not be logged, so I suggest to insert another check at HTTPLoggingInterceptor line 238 else if (responseBody.contentLength() <= 0) { logger.log("<-- END HTTP (content length <= 0)"); }

Workaround is not to log the Response BODY. (Real life example: Microsoft PowerBI API returnes a 200 OK response with a 0 byte gzip body rather than an empty json.)

swankjesse commented 5 years ago

Can you report the bug to the maintainers of the Microsoft PowerBI API? Their API is wrong.

skristof commented 5 years ago

@swankjesse I'm not sure about it. It's a response to a POST request.

The method hasBody(Response response) in okhttp3.internal.http.HttpHeaders returns true if the response code is 200. In case of a 200 response with empty body (Content-Length: 0) shouldn't it return false?

Full header: access-control-allow-credentials →true access-control-allow-origin →chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop cache-control →no-store, must-revalidate, no-cache content-encoding →gzip content-length →0 content-type →application/octet-stream date →Sun, 25 Nov 2018 13:40:47 GMT requestid →709adf93-2f60-4a7e-9fdb-dfbdc5457195 server →Microsoft-HTTPAPI/2.0,Microsoft-HTTPAPI/2.0 Microsoft-HTTPAPI/2.0 status →200 strict-transport-security →max-age=31536000; includeSubDomains x-content-type-options →nosniff x-frame-options →deny

swankjesse commented 5 years ago

The content-encoding is not Gzip because it doesn’t have the required 10-byte Gzip header.

kngmat004 commented 2 years ago

Getting the same issue on a 202 No Content with a zero length response body

yschimke commented 2 years ago

@kngmat004 you should report the problem to whoever hosts the server. If it's the same as above it's a bug.

If you really need to handle it in the client, because the server can't be fixed, consider using a network interceptor to change headers to work around it.

If you think it's a bug in OkHttp please provide a reproducible example.