EOFException in RealBufferedSource.readUtf8LineStrict #1114
Comments
|
I haven't been able to reproduce this. Punting to 2.2. |
|
@swankjesse I am seeing a few of those in production. How can I help debugging? |
|
@niqo01 can you reproduce locally or are you getting this through Crashlytics/Bugsnag etc. ? |
|
@swankjesse Getting through Crashlytics only. If you think about logs which would help debugging, I would be glad to add them to the next release. |
|
@niqo01 any pattern in device maker or Android version? I'll add something to OkHttp itself to provide more context when this is triggered. |
|
@swankjesse you can have a look at the crashlytics report here: http://crashes.to/s/816499ead0b |
|
OkHttp 2.1. This is the one user's device's info. I hope this may help you. Simliar comment can be found here: |
|
Hello @swankjesse , what I don't understand is why the error comes so quickly and not seeing a response log. My experience is that either my server is down or a problem connecting to the server because of spotty connection that causes an EOFException for me. 12-10 17:21:27.453 30472-30652/? D/Retrofit log﹕ ---> HTTP POST https://placeholder.server.com//core/b1c51a7ec5204/ |
|
@swankjesse In the previous issue (#803), you theorized:
Are you referring to the fact that if the response gives HTTP 100 (HttpConnection:199), HttpConnection continues the loop to parse the StatusLine again (HttpConnection:187)? I've attached the debugger to see if that's the case, and it's not; the exception is thrown the first time around, in my case on a HTTP 204. I've been trying to put together a minimum working example of this problem, but to no avail. I'm only seeing it in a production environment where the API returns HTTP 204 with an empty body on a POST request. I'm suspicious that perhaps the response coming in contains no newline '\n' character at all, as looking at RealBufferedSource:192 suggests that's the only cause of this exception. As the HTTP response should always contain at least one such character following the header, I'm properly puzzled. On OkHttp 2.1.0, the line numbers appear to be slightly different; my stack trace is: |
|
Is there a fix for this? I get the exception quite often java.io.EOFException
at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:192)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:187)
at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:78)
at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:665)
at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:429)
at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:374)
at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:469)
at retrofit.client.UrlConnectionClient.readResponse(UrlConnectionClient.java:73)
at retrofit.client.UrlConnectionClient.execute(UrlConnectionClient.java:38)
at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:321)
at retrofit.RestAdapter$RestHandler.access$100(RestAdapter.java:220)
at retrofit.RestAdapter$RestHandler$2.obtainResponse(RestAdapter.java:278)
at retrofit.CallbackRunnable.run(CallbackRunnable.java:42)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at retrofit.Platform$Android$2$1.run(Platform.java:142)
at java.lang.Thread.run(Thread.java:818) |
|
This might add some context: |
|
Yes, this would indeed be useful. I haven't grabbed the latest for a new test, but it seems that the newline is missing in empty body responses (such as HTTP 204) from some servers. Oddly, it's entirely random. I'll dump the new exception when I encounter it again. |
|
Might be caused by attempting to parse SPDY or HTTP/2.0 as HTTP/1.1. We had a bug on desktop Java where our ALPN implementation wasn't always telling us the negotiated protocol. With the new information in-hand from Okio's update, I'm going to punt this to 2.3 since there's no further action to take for the 2.2 release. |
|
@swankjesse Please note my extensive comment on this Retrofit issue. |
|
@swankjesse After many (many!) tries where everything just works hunky dory, I've finally gotten it to fail again with OkHttp 2.2. I don't know what to say than that it appears to be completely at random. As with @johnjohndoe's report, the buffer is simply empty. Unlike his report, this is coming from a Apache 2.2.15 on CentOS, running PHP 5.4.36. |
|
Perhaps it would be useful for logging that the headers are output before the rest of the response body is attempted to be read? Presently, it bombs out with the The issue is so terribly difficult to reproduce that I can't attach the debugger and hope for it to occur on a breakpoint. |
|
Jesse and I talked about a Retrofit-like logging system for stupid-easy
|
|
Yes, I can imagine, and looking at where those headers are read, it wouldn't be an ideal place to add logging. I took another look at the stack trace, and if I understand correctly, noticed that it doesn't even get to reading the headers. The exception is thrown from HttpConnection:187, which seems to suggest that the response is a single line. With Jesse's added details in the stack trace, it appears that the response is actually completely empty. No status line, no headers, no body, nothing. I'll throw together a bash script to test the API using cURL and see if it ever gets empty responses, but it sounds very strange to me. |
|
Hi, I met this problem every time trying to send an http request. Sure the Android OS of the device I used to test is bizarrely customized, but it's still worth a look. Device Info: Library Info: |
|
An additional informartion: |
|
Our users also facing this issue: Devices: For some users it not work with WiFi connection, while on 3G all is ok. |
|
An update that maybe help others. I had the same issue for a long time. Since i updated to retrofit v1.9.0, okhttp 2.2.0, urlconnection 2.2.0 i haven't encountered the problem since. |
|
@swankjesse your comment was probably ment for @coreform. We have a problem on real device. |
|
Jesse, I'm happy to run the test, but in the meantime I'd like to emphasize On Thu, Mar 19, 2015, 19:30 epint [email protected] wrote:
|
|
Thanks @pflammertsma. I think there are two distinct problems here. I'm going to close this issue and re-open two issues for each of the two problems.
If you have an otherwise-normal, CTS-passing device that is getting corrupt, non-empty responses, then my hypothesis is invalidated & please let me know! |
|
Any specific reason for this kind of EOF Exception error occurrence (using retrofit) ??? we all know this is issue facing with all, but i want to know exact problem behind this kind of issue. |
|
for android 4.2.2 (vivo y17t) java.io.IOException: unexpected end of stream on Connection{59.46.115.124:11800, proxy=DIRECT@ hostAddress=59.46.115.124 cipherSuite=none protocol=http/1.1} (recycle count=0) |
|
apacheclient no problem,but use okhttp have this problem,log detail: 03-31 13:29:27.055: I/RetrofitCallback(3661): error.toString() :retrofit.RetrofitError: unexpected end of stream on Connection{:18083, proxy=DIRECT@ hostAddress=*** cipherSuite=none protocol=http/1.1} (recycle count=0) |
|
I had the same issue and solved it. After closer inspection I notices that after the status code, the server didn't gave a description. But this is broken: So in my example the (somewhat exotic) http server didn't return a reason after the status code. |
|
Disable jit: see this: |
|
Got the same error in our prod environment. I have validated the health of Load balancer and instnace and both seem to be working fine. Caused by: java.io.EOFException |
|
Currently getting the dreaded EOFException. Running: Project dependency: Adapter configuration: Thanks, listening for updates. |
|
Maybe malformed/different version gzip reply from server(?) public static void main(String[] args) {
final OkHttpClient client = new OkHttpClient();
Request request = new Request.Builder()
.url("http://sosu.qidian.com/ajax/search.ashx?method=Search&keyword=TEST")
.addHeader("Referer", "http://sosu.qidian.com/")
.build();
Response response = null;
String res = null;
try {
response = client.newCall(request).execute();
res = response.body().string();
} catch (IOException e) {
e.printStackTrace();
}
if (response != null && res != null)
System.out.println(res);
}By adding To check if is header dependent error, I have also test with curl using same headers, and the result has been properly replied. I've also created === BEGIN ===
<?php sleep(1);
for ($i = 0; $i < 80000; $i++) {
echo mt_rand();
}
sleep(1); ?>
=== END ===
|
|
An ssl issue caused the no response bug with me. |
|
Got the same error java.io.IOException: unexpected end of stream on Connection{p33.qhimg.com:80, proxy=DIRECT@ hostAddress=42.81.9.47 cipherSuite=none protocol=http/1.1} (recycle count=1) |
|
OKHttp 2.4 doesn't work on some HUAWEI devices .. eg: for android 4.2.2 (HUAWEI Y518-T00) wifi and 3G Currently getting the dreaded EOFException：like this |
|
Got the same error okhttp-2.4.0 |
|
added android:vmSafeMode="true" and problem is gone! |
|
I'm getting this from a server app where we're using OkHttp 2.2.0 under Retrofit. I'm making an HTTPS POST request to a slow-responding service and it ends up getting retried because this exception is thrown. The retry is causing us problems because the request isn't idempotent. If I set OkHttp's readTimeout lower it stops happening because the read times out before this exception is thrown. Please let me know if I can help debugging. |
This is test solution for Enforta from this issue comment: square/okhttp#1114 (comment)
|
Hey dude, I can reproduce this with private code. In that code, I can switch between OkHttp which exhibits the issue, and UniRest which does not. With some effort I could make a standalone proof for y'all. RSVP :) mailto: @swankjesse |
|
I got the same issues. For some reason an empty string is not accepted when parsing headers |
and others
A few people have reported this. Needs investigation & fix.
The text was updated successfully, but these errors were encountered: