Okhttp: EOFException in RealBufferedSource.readUtf8LineStrict

Created on 1 Nov 2014  Â·  100Comments  Â·  Source: square/okhttp

A few people have reported this. Needs investigation & fix.

java.io.EOFException: null
    at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:154) ~[na:0.0]
    at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:189) ~[na:0.0]
    at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:101) ~[na:0.0]
    at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:676) ~[na:0.0]
    at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:426) ~[na:0.0]
    at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:371) ~[na:0.0]
    at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:466) ~[na:0.0]
    at com.squareup.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105) ~[na:0.0]
bug

Most helpful comment

Getting this error when trying to call a JSON service from a Nexus 5 Lollipop emulator using a http proxy.
It seems to work on an actual Nexus 5 device without proxy.

Originally I was using a DefaultHttpClient.execute() with a Proxy set in the params. This worked. Removing the proxy and defining it via emulator parameters gives me this error.

Update: Different service (offering xml) works with the exact same call.

All 100 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
I didn't recognized a possible pattern in device maker or Android version or specific HTTP request.

OkHttp 2.1.
Device: Coolpad 8297.
Version: Android 4.2.2.
Same issues. I can confirm this device would cause this EOFException (my two users have this device reported this).

This is the one user's device's info. I hope this may help you.

Model number                      Coolpad 8297
Android version                   4.2.2 MIUI V5
MIUI version (An android rom)     MIUI-4.9.26
Processor                         8-core 1.7GHZ
RAM                               2.00 GB
ROM                               8.00 GB
Baseband version                  MOLY.WR8.W1315.MD.W
                                  G.MP.V19.P2,2014/03/11
                                                   00:55
Kernel version                    3.4.39

Simliar comment can be found here:
https://github.com/square/okhttp/issues/803#issuecomment-60895738

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/
12-10 17:21:27.463 30472-30652/? D/Retrofit log﹕ User-Agent: Android
12-10 17:21:27.463 30472-30652/? D/Retrofit log﹕ Content-Type: application/json; charset=UTF-8
12-10 17:21:27.463 30472-30652/? D/Retrofit log﹕ Content-Length: 121
12-10 17:21:27.463 30472-30652/? D/Retrofit log﹕ ---> END HTTP (121-byte body)
12-10 17:21:29.275 30472-30652/? D/Retrofit log﹕ ---- ERROR https://placeholder.server.com//core/b1c51a7ec5204/
12-10 17:21:29.295 30472-30652/? D/Retrofit log﹕ java.io.EOFException
at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:154)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:189)
at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:101)

@swankjesse In the previous issue (#803), you theorized:

At first glance it looks like bad connection reuse, but that should be recovered from & retried automatically. Is this a POST request?

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:

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 com.squareup.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
    at com.squareup.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:25)
    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.invoke(RestAdapter.java:240)
    [...]

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:
https://github.com/square/okio/pull/104

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.

java.io.EOFException: \n not found: size=0 content=...
    at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
    at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:187)
    at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
    at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:791)
    at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:678)
    at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:431)
    at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:376)
    at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:471)
    at com.squareup.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
    at com.squareup.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:25)
    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.invoke(RestAdapter.java:240)
    at $Proxy2.locationFinishSession(Native Method)
    at com.vebego.ally.proxies.LocationSessionProxy$2.doRequest(LocationSessionProxy.java:47)
    at com.vebego.ally.SyncService$2.doInBackground(SyncService.java:269)
    at com.vebego.ally.SyncService$2.doInBackground(SyncService.java:259)
    at android.os.AsyncTask$2.call(AsyncTask.java:288)
    at java.util.concurrent.FutureTask.run(FutureTask.java:237)
    at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:231)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
    at java.lang.Thread.run(Thread.java:841)

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 ---- ERROR message line immediately after the ---> END HTTP line.

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
things like this. We have to be careful, though, because both headers and
the response body can come from different places. In this case you want the
headers logged before the body is read which is a very, very fine level of
logging.
On Jan 7, 2015 6:49 PM, "Paul Lammertsma" [email protected] wrote:

Perhaps it would be useful for logging that the headers are output before
the rest of the response body is attempted to be read? The issue is so
terribly difficult to reproduce that I can't attach the debugger and hope
for it to occur on a breakpoint.

—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/1114#issuecomment-69128693.

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:
device: Coolpad 9976A
Android version: 4.4.2
kernel: 3.4.39

Library Info:
gson-2.3.1
okhttp-2.1.0
okhttp-urlconnection-2.1.0
okio-1.0.1
retrofit-1.8.0

An additional informartion:
When I was single-step debugging the code in DDMS, everything worked fine, I got the response correctly, but when I ran the APP, I got the exception.

Our users also facing this issue:

Caused by java.io.EOFException
okio.RealBufferedSource.readUtf8LineStrict (RealBufferedSource.java:192)
com.squareup.okhttp.internal.http.HttpConnection.readResponse (HttpConnection.java:187)
com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders (HttpTransport.java:78)
com.squareup.okhttp.internal.http.HttpEngine.readResponse (HttpEngine.java:665)
com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute (HttpURLConnectionImpl.java:429)
com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse (HttpURLConnectionImpl.java:374)
com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode (HttpURLConnectionImpl.java:469)
retrofit.client.UrlConnectionClient.readResponse (UrlConnectionClient.java:73)
retrofit.client.UrlConnectionClient.execute (UrlConnectionClient.java:38)
retrofit.RestAdapter$RestHandler.invokeRequest (RestAdapter.java:321)
retrofit.RestAdapter$RestHandler.invoke (RestAdapter.java:240)

Devices:
Jiayu GF2 (4.2.2)
MyAudio Blade Smartphone
Akai Glory 3
Concorde Smartphone 5005NFC
THL T200

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.

I was able to fix this error for me.

Here was my stacktrace before:

01-26 21:50:38.670    2727-2752/com D/Retrofit﹕ java.io.EOFException: \n not found: size=0 content=...
            at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
            at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:187)
            at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
            at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:791)
            at com.squareup.okhttp.internal.http.HttpEngine.access$200(HttpEngine.java:90)
            at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:784)
            at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:645)
            at com.squareup.okhttp.Call.getResponse(Call.java:263)
            at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:219)
            at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:192)
            at com.squareup.okhttp.Call.execute(Call.java:79)
            at retrofit.client.OkClient.execute(OkClient.java:53)
            at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:326)
            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)

I noticed one header had a couple of newlines -- Which seemed to be the root problem.

For me specifically, I was encoding newlines with the following line of code:

Base64.encodeToString(bytes, Base64.DEFAULT);

I changed to:

Base64.encodeToString(bytes, Base64.NO_WRAP);

and it worked.

I am also seeing this exact issue using retrofit 1.9.0, okhttp-urlconnection 2.2.0. I get the same exception every time I use a certain specific API call. The API call is a simple POST with a text/plain file. Is there a workaround for this?

:+1:

Hello, we have the same problem. Everything works on cca 3000 devices, but on one we get this error everytime. The device is called JIAYU JY-G2F with Android 4.2.2.

Here is the stacktrace we get:

Caused by: java.io.EOFException: \n not found: size=45 content=32320d0a7b225374616e6a6541706c696b6163696a65223a7b22536966726122...
       at okio.RealBufferedSource.readUtf8LineStrict(SourceFile:200)
       at com.squareup.okhttp.internal.http.HttpConnection$ChunkedSource.readChunkSize(SourceFile:468)
       at com.squareup.okhttp.internal.http.HttpConnection$ChunkedSource.read(SourceFile:450)
       at okio.RealBufferedSource$1.read(SourceFile:298)
       at java.io.InputStream.read(InputStream.java:163)
       at org.springframework.util.FileCopyUtils.copy(SourceFile:111)
       at org.springframework.util.FileCopyUtils.copyToByteArray(SourceFile:164)
       at org.springframework.http.converter.ByteArrayHttpMessageConverter.readInternal(SourceFile:59)
       at org.springframework.http.converter.ByteArrayHttpMessageConverter.readInternal(SourceFile:38)
       at org.springframework.http.converter.AbstractHttpMessageConverter.read(SourceFile:147)
       at org.springframework.web.client.HttpMessageConverterExtractor.extractData(SourceFile:76)
       at org.springframework.web.client.RestTemplate$ResponseEntityResponseExtractor.extractData(SourceFile:655)
       at org.springframework.web.client.RestTemplate$ResponseEntityResponseExtractor.extractData(SourceFile:641)
       at org.springframework.web.client.RestTemplate.doExecute(SourceFile:484)
       at org.springframework.web.client.RestTemplate.execute(SourceFile:447)
       at org.springframework.web.client.RestTemplate.exchange(SourceFile:422)
       at com.hrc.eb.mobile.android.hibismobile.rest.RestClient.invoke(SourceFile:290)
       at com.hrc.eb.mobile.android.hibismobile.rest.RestClient.get(SourceFile:349)
       at com.hrc.eb.mobile.android.hibismobile.client.StanjeAplikacijeClient$1.call(SourceFile:35)
       at rx.Observable.unsafeSubscribe(SourceFile:7600)
       at rx.internal.operators.OperatorSubscribeOn$1$1.call(SourceFile:62)
       at rx.internal.schedulers.ScheduledAction.run(SourceFile:45)
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390)
       at java.util.concurrent.FutureTask.run(FutureTask.java:234)
       at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:153)
       at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
       at java.lang.Thread.run(Thread.java:838)

Not sure if this is the problem, but the content size is actually 34 (hex: 22). If we decode debug content we get:

22 {"StanjeAplikacije":{"Sifra"

Actual body is:
{"StanjeAplikacije":{"Sifra":"0"}}

Not sure, but maybe it's worth to take a look, why debug content size is 45?

Once more, this works on every other device, on specific device it fails everytime. Same thing can be reproduced with Okhttp 2.0.0 and 2.2.0. It works with Apache HTTP client .

And now, complete trace of response, maybe it helps:

=> Send header, 248 bytes (0xf8)
0000: 47 45 54 20 2f 6d 6f 62 69 6c 65 2f 72 65 73 74 GET /mobile/rest
0010: 73 65 63 2f 70 72 65 76 65 72 6a 61 6e 6a 65 2d sec/preverjanje-
0020: 73 74 61 6e 6a 61 2d 61 70 6c 69 6b 61 63 69 6a stanja-aplikacij
0030: 65 3f 6f 73 3d 32 26 74 69 70 5f 6e 61 70 72 61 e?os=2&tip_napra
0040: 76 65 3d 31 26 76 65 72 7a 69 6a 61 3d 31 2e 31 ve=1&verzija=1.1
0050: 2e 30 20 48 54 54 50 2f 31 2e 31 0d 0a 55 73 65 .0 HTTP/1.1..Use
0060: 72 2d 41 67 65 6e 74 3a 20 63 75 72 6c 2f 37 2e r-Agent: curl/7.
0070: 31 31 2e 30 20 28 69 36 38 36 2d 73 75 73 65 2d 11.0 (i686-suse-
0080: 6c 69 6e 75 78 29 20 6c 69 62 63 75 72 6c 2f 37 linux) libcurl/7
0090: 2e 31 31 2e 30 20 4f 70 65 6e 53 53 4c 2f 30 2e .11.0 OpenSSL/0.
00a0: 39 2e 37 64 20 69 70 76 36 20 7a 6c 69 62 2f 31 9.7d ipv6 zlib/1
00b0: 2e 32 2e 31 0d 0a 48 6f 73 74 3a 20 xx xx xx xx .2.1..Host: xxxx
00c0: xx xx xx xx xx xx xx xx xx 0d 0a 50 72 61 67 6d xxxxxxxxx..Pragm
00d0: 61 3a 20 6e 6f 2d 63 61 63 68 65 0d 0a 61 63 63 a: no-cache..acc
00e0: 65 70 74 3a 61 70 70 6c 69 63 61 74 69 6f 6e 2f ept:application/
00f0: 6a 73 6f 6e 0d 0a 0d 0a                         json....
<= Recv header, 17 bytes (0x11)
0000: 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK.
0010: 0a                                              .
<= Recv header, 108 bytes (0x6c)
0000: 58 2d 50 6f 77 65 72 65 64 2d 42 79 3a 20 53 65 X-Powered-By: Se
0010: 72 76 6c 65 74 2f 33 2e 31 20 4a 53 50 2f 32 2e rvlet/3.1 JSP/2.
0020: 33 20 28 47 6c 61 73 73 46 69 73 68 20 53 65 72 3 (GlassFish Ser
0030: 76 65 72 20 4f 70 65 6e 20 53 6f 75 72 63 65 20 ver Open Source
0040: 45 64 69 74 69 6f 6e 20 20 34 2e 30 20 20 4a 61 Edition  4.0  Ja
0050: 76 61 2f 4f 72 61 63 6c 65 20 43 6f 72 70 6f 72 va/Oracle Corpor
0060: 61 74 69 6f 6e 2f 31 2e 37 29 0d 0a             ation/1.7)..
<= Recv header, 52 bytes (0x34)
0000: 53 65 72 76 65 72 3a 20 47 6c 61 73 73 46 69 73 Server: GlassFis
0010: 68 20 53 65 72 76 65 72 20 4f 70 65 6e 20 53 6f h Server Open So
0020: 75 72 63 65 20 45 64 69 74 69 6f 6e 20 20 34 2e urce Edition  4.
0030: 30 20 0d 0a                                     0 ..
<= Recv header, 49 bytes (0x31)
0000: 43 61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6e Cache-Control: n
0010: 6f 2d 63 61 63 68 65 2c 20 6e 6f 2d 73 74 6f 72 o-cache, no-stor
0020: 65 2c 20 6e 6f 2d 74 72 61 6e 73 66 6f 72 6d 0d e, no-transform.
0030: 0a                                              .
<= Recv header, 32 bytes (0x20)
0000: 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 Content-Type: ap
0010: 70 6c 69 63 61 74 69 6f 6e 2f 6a 73 6f 6e 0d 0a plication/json..
<= Recv header, 37 bytes (0x25)
0000: 44 61 74 65 3a 20 54 68 75 2c 20 30 35 20 46 65 Date: Thu, 05 Fe
0010: 62 20 32 30 31 35 20 30 37 3a 35 34 3a 35 38 20 b 2015 07:54:58
0020: 47 4d 54 0d 0a                                  GMT..
<= Recv header, 28 bytes (0x1c)
0000: 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e Transfer-Encodin
0010: 67 3a 20 63 68 75 6e 6b 65 64 0d 0a             g: chunked..
<= Recv data, 40 bytes (0x28)
0000: 32 32 0d 0a 7b 22 53 74 61 6e 6a 65 41 70 6c 69 22..{"StanjeApli
0010: 6b 61 63 69 6a 65 22 3a 7b 22 53 69 66 72 61 22 kacije":{"Sifra"
0020: 3a 22 30 22 7d 7d 0d 0a                         :"0"}}..
<= Recv data, 1 bytes (0x1)
0000: 30                                              0
<= Recv data, 4 bytes (0x4)
0000: 0d 0a 0d 0a                                     ....
== Info: Connection #0 left intact

I think we can try the last version 2.2.0.Then test this issunes

FYI, calling setRetryOnConnectionFailure(true) may fix this for you.

I have observed this issue post addition of setRetryOnConnectionFailure(true). Seems to be less often than it was, but still it's manifested.

Same here when trying setRetryOnConnectionFailure(true). I still get the problem, not sure if it is less often though.

Device : OPO, android Version 4.4.4
compile 'com.google.code.gson:gson:2.2.+'
compile 'com.squareup.okhttp:okhttp:2.2.0'
compile 'com.squareup.okhttp:okhttp-urlconnection:2.2.0'
compile 'com.squareup.retrofit:retrofit:1.9.0'

Still having the same issue :
java.io.EOFException: \n not found: size=0 content=...
at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:187)
at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:791)

Request :

HTTP POST
Dbname: demo
Apikey: 000000000000000
Content-Type: application/json; charset=UTF-8
Content-Length: 112
{"dbname":"demo","sid":"2c463dfb5d648797d248618e2b921bfda5f65ee0","udid":"63d476fdc0cbc07a"}

I have found a request/response that will 100% yield this issue using Nexus5 Lollipop emulator (running on HAXM on Windows 7 64bit if that makes any difference).

I was just about to try tampering with the response, so intercepted the request using Burpsuite, and BAM the issue manifested (i.e. without any HTTP response at all):

System.err﹕ retrofit.RetrofitError: \n not found: size=0 content=...

This to me suggests the issue stems from the request, rather than the response. The request is a POST containing empty body (i.e. Content-Length: 0), following is a scrubbed version of the HTTP request:

POST /lala-bleh/rest/yhgmt/woopsie/zomg/AMAGAD HTTP/1.1
Accept: application/json
Authorization: Basic thiswaslegitbeforeiscrubbedit==
Content-Length: 0
Host: abcdef.hijklmnopqrs.tuvwxyandz.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/2.2.0

Getting this error when trying to call a JSON service from a Nexus 5 Lollipop emulator using a http proxy.
It seems to work on an actual Nexus 5 device without proxy.

Originally I was using a DefaultHttpClient.execute() with a Proxy set in the params. This worked. Removing the proxy and defining it via emulator parameters gives me this error.

Update: Different service (offering xml) works with the exact same call.

+1 same here, but i got Nexus 4 with lolipop

+1 Same problem.
HTC One_E8
DEVICE
Portrait
ORIENTATION
52%
BATTERY
4.4.2
Portrait
26%
RAM
5%
DISKSPACE
Caused by: java.io.EOFException
at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:192)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:189)
at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:101)
at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:676)
at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:426)
at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:371)
at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:466)
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.invoke(RestAdapter.java:240)

I suggest to test manually the URL you are calling.
I had the same problem, but eventually I realized it was caused by a wrong response by the webservices, for some particular calling parameters.

@dbaroncelli Can you provide some more details? Under which circumstances can a response yield this exception in OkHttp?

@pflammertsma, in my case it was a webservice not serving a valid http response. For anyone familiar with Go, it was a case when the Go app finds a runtime error and goes into panic, and it is not able to respond to a request.

@dbaroncelli Do you have any idea what the raw response from the API is? Does it actually contain 0 bytes as OkHttp suggests (i.e. also omitting the header)?

OK, I can check, give me some minutes to reproduce it (I had already fixed it server-side ;-) )

I can confirm! 0 bytes, no header!

@dbaroncelli Thanks, this gives a whole lot of insight. Perhaps the attached backend has become overloaded.

As I mentioned earlier, this is coming from a Apache 2.2.15 on CentOS, running PHP 5.4.36 (on this staging server, there's no memcache or anything of the sort). My suspicion is that PHP is running out of memory and Apache is dumping the 0-byte response, but I'll only know for sure after looking into this together with the backend team.

I've prepared a test to effectively overload the server with the request, and we'll see if it fails as the server becomes overloaded.

With https://github.com/square/okhttp/pull/1487, I'm added more context to the exception. If anyone is currently seeing this problem and wants to further investigate, please grab the latest snapshot and see what it says when it fails!

We are experiencing this on ZOPO ZP998 phone, every other phone works. Unfortunately I can't test this with the latest version (with improved exception loggin), because this is a customer's phone. This is a HTTPS request. Here is the stacktrace:

03-11 13:15:00.516    4980-5804/﹕ SimpleHTTP.Connection failed: \n not found: size=17 content=03007fa861b9d60200000d0a300d0a0d0a...
java.io.EOFException: \n not found: size=17 content=03007fa861b9d60200000d0a300d0a0d0a...
        at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
        at com.squareup.okhttp.internal.http.HttpConnection.readHeaders(HttpConnection.java:209)
        at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:195)
        at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
        at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:791)
        at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:678)
        at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:431)
        at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:376)
        at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:471)
        at com.squareup.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
        at com.squareup.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:25)

could you pls tell me how to fix this?i got the same proble everytime in vivo phone, 80 users got this problem and can't load image with picasso. the log like this,i use the version okhttp-2.2.0;okio-1.3.0

java.io.EOFException: \n not found: size=162111 content=34ef1ac5f19f5ebcd766be9ad1b4b6bcd71f5231851379a01663b33ba3e9d71e...
03-17 10:07:05.248 12962-13079/com.lingan.seeyou W/System.err﹕ at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
03-17 10:07:05.248 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpConnection.readHeaders(HttpConnection.java:209)
03-17 10:07:05.248 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:195)
03-17 10:07:05.248 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
03-17 10:07:05.249 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:791)
03-17 10:07:05.249 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine.access$200(HttpEngine.java:90)
03-17 10:07:05.249 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:784)
03-17 10:07:05.249 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:645)
03-17 10:07:05.249 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.Call.getResponse(Call.java:263)
03-17 10:07:05.249 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:219)
03-17 10:07:05.250 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:192)
03-17 10:07:05.250 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.Call.execute(Call.java:79)
03-17 10:07:05.250 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.picasso.OkHttpDownloader.load(OkHttpDownloader.java:116)
03-17 10:07:05.250 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.picasso.NetworkRequestHandler.load(NetworkRequestHandler.java:47)
03-17 10:07:05.250 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.picasso.BitmapHunter.hunt(BitmapHunter.java:215)
03-17 10:07:05.251 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.picasso.BitmapHunter.run(BitmapHunter.java:162)
03-17 10:07:05.251 12962-13079/com.lingan.seeyou W/System.err﹕ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390)
03-17 10:07:05.251 12962-13079/com.lingan.seeyou W/System.err﹕ at java.util.concurrent.FutureTask.run(FutureTask.java:234)
03-17 10:07:05.251 12962-13079/com.lingan.seeyou W/System.err﹕ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
03-17 10:07:05.251 12962-13079/com.lingan.seeyou W/System.err﹕ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
03-17 10:07:05.251 12962-13079/com.lingan.seeyou W/System.err﹕ at java.lang.Thread.run(Thread.java:838)
03-17 10:07:05.252 12962-13079/com.lingan.seeyou W/System.err﹕ at com.squareup.picasso.Utils$PicassoThread.run(Utils.java:391)

@iceAnson something is corrupt on your HTTP server. That response is invalid HTTP. Can you confirm that the request works with curl?

@swankjesse
no,it works fine at other phone,like sunsang,htc;only at some device happen this,like vivo,coolpad phone,so it's not the server problem,and the vivo phone get this problem erveytime ,users can't load image with picasso( picasso use the okhttp to download image),do you need something i can provide like log or other sth to debug this problem?

@swankjesse
do you have any idea to fix this problem?

There's more debug info in 2.3.0. Trying that to start can't hurt.

@swankjesse
ok, 2.3.0 still doesn't work. the problem's phone is not herr ,i will debug it tomorrow and post log to you .

@swankjesse
this is the 2.3.0 log,i still doesn't work;

I/SurfaceTextureClient﹕ STC::queueBuffer fps:4.04, dur:1236.68, max:248.55, min:246.33
03-18 08:49:51.603 29563-29563/com.lingan.seeyou I/SurfaceTextureClient﹕ STC::queueBuffer fps:4.04, dur:1237.61, max:247.91, min:247.24
03-18 08:49:52.840 29563-29563/com.lingan.seeyou I/SurfaceTextureClient﹕ STC::queueBuffer fps:4.04, dur:1237.12, max:247.65, min:247.17
03-18 08:49:54.078 29563-29563/com.lingan.seeyou I/SurfaceTextureClient﹕ STC::queueBuffer fps:4.04, dur:1237.33, max:247.94, min:246.63
03-18 08:49:55.323 29563-29563/com.lingan.seeyou I/SurfaceTextureClient﹕ STC::queueBuffer fps:4.01, dur:1245.60, max:255.82, min:244.99
03-18 08:49:56.326 29563-29563/com.lingan.seeyou I/SurfaceTextureClient﹕ STC::queueBuffer fps:3.99, dur:1002.80, max:255.62, min:247.03
03-18 08:49:57.558 29563-29563/com.lingan.seeyou I/SurfaceTextureClient﹕ STC::queueBuffer fps:4.06, dur:1231.98, max:251.12, min:242.90
03-18 08:49:58.796 29563-29563/com.lingan.seeyou I/SurfaceTextureClient﹕ STC::queueBuffer fps:4.04, dur:1237.61, max:250.06, min:244.39
03-18 08:50:00.033 29563-29563/com.lingan.seeyou I/SurfaceTextureClient﹕ STC::queueBuffer fps:4.04, dur:1237.47, max:249.23, min:246.06
03-18 08:50:00.103 29563-29627/com.lingan.seeyou W/System.err﹕ java.io.IOException: unexpected end of stream on Connection{img.seeyouyima.com:80, proxy=DIRECT@ hostAddress=117.25.156.199 cipherSuite=none protocol=http/1.1} (recycle count=0)
03-18 08:50:00.104 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:210)
03-18 08:50:00.104 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
03-18 08:50:00.104 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:830)
03-18 08:50:00.104 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine.access$200(HttpEngine.java:95)
03-18 08:50:00.105 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:823)
03-18 08:50:00.105 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:684)
03-18 08:50:00.105 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.Call.getResponse(Call.java:272)
03-18 08:50:00.105 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:228)
03-18 08:50:00.105 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:199)
03-18 08:50:00.106 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.Call.execute(Call.java:79)
03-18 08:50:00.106 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.picasso.OkHttpDownloader.load(OkHttpDownloader.java:118)
03-18 08:50:00.106 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.picasso.NetworkRequestHandler.load(NetworkRequestHandler.java:47)
03-18 08:50:00.108 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.picasso.BitmapHunter.hunt(BitmapHunter.java:209)
03-18 08:50:00.108 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.picasso.BitmapHunter.run(BitmapHunter.java:159)
03-18 08:50:00.108 29563-29627/com.lingan.seeyou W/System.err﹕ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390)
03-18 08:50:00.109 29563-29627/com.lingan.seeyou W/System.err﹕ at java.util.concurrent.FutureTask.run(FutureTask.java:234)
03-18 08:50:00.109 29563-29627/com.lingan.seeyou W/System.err﹕ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
03-18 08:50:00.109 29563-29627/com.lingan.seeyou W/System.err﹕ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
03-18 08:50:00.110 29563-29627/com.lingan.seeyou W/System.err﹕ at java.lang.Thread.run(Thread.java:838)
03-18 08:50:00.117 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.picasso.Utils$PicassoThread.run(Utils.java:391)
03-18 08:50:00.129 29563-29627/com.lingan.seeyou W/System.err﹕ Caused by: java.io.EOFException: \n not found: size=26346 content=73b863b8fa63a579f358f86ffe1338d3fb1ae7ec26c998c1f6197717f3061b66...
03-18 08:50:00.130 29563-29627/com.lingan.seeyou W/System.err﹕ at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
03-18 08:50:00.131 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpConnection.readHeaders(HttpConnection.java:219)
03-18 08:50:00.133 29563-29627/com.lingan.seeyou W/System.err﹕ at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:198)
03-18 08:50:00.133 29563-29627/com.lingan.seeyou W/System.err﹕ ... 19 more
03-18 08:50:00.134 29563-29627/com.lingan.seeyou D/Picasso﹕ Hunter executing [R4]+12s
03-18 08:50:00.138 29563-29627/com.lingan.seeyou D/libc-netbsd﹕ getaddrinfo: sc.seeyouyima.com get result from proxy >>
03-18 08:50:00.139 29563-29627/com.lingan.seeyou I/System.out﹕ propertyValue:true
03-18 08:50:00.140 29563-29627/com.lingan.seeyou I/System.out﹕ [CDS]rx timeout:40000
03-18 08:50:00.140 29563-29627/com.lingan.seeyou I/System.out﹕ [socket][15] connection sc.seeyouyima.com/218.5.238.215:80;LocalPort=38772(45000)
03-18 08:50:00.141 29563-29627/com.lingan.seeyou I/System.out﹕ [CDS]connect[sc.seeyouyima.com/218.5.238.215:80] tm:45
03-18 08:50:00.141 29563-29627/com.lingan.seeyou D/Posix﹕ [Posix_connect Debug]Process com.lingan.seeyou :80
03-18 08:50:00.150 29563-29627/com.lingan.seeyou I/System.out﹕ [socket][/192.168.1.30:38772] connected

@swankjesse
does that help?you can add more debug info and send me to debug by email,and i will feedback as soon as possible,maybe we can fix this problem soon.

@iceAnson: I suspect it's a problem with your webserver. It's not returning well-formed HTTP for this request. Got the full URL?

@swankjesse
url:http://sc.seeyouyima.com/icon/53f3f540c7233.png

@swankjesse
but why other phone work fine with this url.?

@swankjesse
here is detail log:

http://sc.seeyouyima.com/icon/5438e8e45cbe4.png
GET /icon/5438e8e45cbe4.png HTTP/1.1

image content is:

12,372 bytes

86w x 86h

Format: PNG
Color: RGB+Alpha 8bit

COMMENTS (919 bytes)

COMMENT: 'Software'='Adobe ImageReady'
iCOMMENT [Plain ]: 'XML:com.adobe.xmp/'=' /rdf:Description /rdf:RDF /x:xmpmeta '

Can you try Charles proxy with the device that's causing problems?

@swankjesse please look again at my report on this issue from from month ago. We're having the same issue as @iceAnson, it works on all but one device. I provided logs from response (and pointed to possible size mismatch).

@swankjesse
here is the detail log:

http://sc.seeyouyima.com/icon/5438e8e45cbe4.png
GET /icon/5438e8e45cbe4.png HTTP/1.1

1
2

@swankjesse

and the hexView like below:

3

@epint is there a missing CRLF (0e 0a) between the last header line and the response body?

@swankjesse is it useful?

Run this program? I want to see if the bytes we get are the ones we expect. Paste the output when you have something!

    Socket socket = new Socket("sc.seeyouyima.com", 80);

    BufferedSink sink = Okio.buffer(Okio.sink(socket));
    sink.timeout().timeout(5, TimeUnit.SECONDS);
    sink.writeUtf8("GET /icon/5438e8e45cbe4.png HTTP/1.1\r\n");
    sink.writeUtf8("Accept-Encoding: gzip\r\n");
    sink.writeUtf8("User-Agent: okhttp/2.3.0\r\n");
    sink.writeUtf8("Connection: Keep-Alive\r\n");
    sink.writeUtf8("Host: sc.seeyouyima.com\r\n");
    sink.writeUtf8("\r\n");
    sink.flush();


    Source source = Okio.buffer(Okio.source(socket));
    Buffer buffer = new Buffer();
    while (source.read(buffer, 2048) != -1) {
      System.out.println(buffer.readByteString().hex());
    }

ok,hold on

When I run it on my desktop, I get hex that corresponds to:

HTTP/1.1 200 OK
Date: Wed, 18 Mar 2015 00:32:36 GMT
Server: nginx/1.4.4
Content-Type: image/png
Content-Length: 12372
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 2592000
Cache-Control: public, max-age=31536000
Content-Disposition: inline; filename="5438e8e45cbe4.png"
Content-Transfer-Encoding: binary
ETag: "Fo36srH0XgSuMch_AL-fTQ5hR-eS"
X-Log: mc.g;IO
X-Reqid: -XoAAIGdAKsti8ET
X-Whom: nb263
X-Qiniu-Zone: 0
Age: 1
X-Via: 1.1 ych59:8104 (Cdn Cache Server V2.0), 1.1 taizhou40:5 (Cdn Cache Server V2.0)
Connection: keep-alive

(followed by a PNG file)

Just ran OKHttp 2.3.0 against that POST request I mentioned earlier. As with OkHttp 2.2.0, this is occurring every time this request is made using N5 Lollipop emulator (windows 7 64bit with HAXM) running through burpsuite proxy. The error manifests whether the response comes through or not (i.e. intercept OFF vs intercept ON in burp). The OkHttp 2.3.0 logs:

retrofit.RetrofitError: unexpected end of stream on Connection{scrubbed:80, proxy=DIRECT@ hostAddress=scrubbed cipherSuite=none protocol=http/1.1} (recycle count=0)
at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:395)
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)
Caused by: java.io.IOException: unexpected end of stream on Connection{scrubbed:80, proxy=DIRECT@ hostAddress=scrubbed cipherSuite=none protocol=http/1.1} (recycle count=0)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:210)
at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:830)
at com.squareup.okhttp.internal.http.HttpEngine.access$200(HttpEngine.java:95)
at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:823)
at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:684)
at com.squareup.okhttp.Call.getResponse(Call.java:272)
at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:228)
at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:199)
at com.squareup.okhttp.Call.execute(Call.java:79)
at retrofit.client.OkClient.execute(OkClient.java:53)
at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:326)
... 7 more
Caused by: java.io.EOFException: \n not found: size=0 content=...
at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:190)
... 18 more

Fortunately this is not manifesting on a real N5 Lollipop device without proxy, having trouble blocking responses with Charles as N5/OkHttp seems to be ignoring the proxy setting setup for the WIFI connection.

Have also confirmed that the response hex contains CRLF (0d 0a) between header and body (there's 2x CRLF, one being the end of header).

@coreform try this on your OkHttpClient:

    client.setProxy(new Proxy(Proxy.Type.HTTP, new InetSocketAddress("192.168.x.y", 8888)));

thanks @swankjesse , now with the real N5 device really going through Charles AND with Charles blocking responses, the error manifests:

retrofit.RetrofitError: unexpected end of stream on Connection{scrubbed:80, proxy=HTTP@/192.168.7.93:8888 hostAddress=192.168.7.93 cipherSuite=none protocol=http/1.1} (recycle count=0)
at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:395)
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)
Caused by: java.io.IOException: unexpected end of stream on Connection{scrubbed:80, proxy=HTTP@/192.168.7.93:8888 hostAddress=192.168.7.93 cipherSuite=none protocol=http/1.1} (recycle count=0)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:210)
at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:830)
at com.squareup.okhttp.internal.http.HttpEngine.access$200(HttpEngine.java:95)
at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:823)
at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:684)
at com.squareup.okhttp.Call.getResponse(Call.java:272)
at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:228)
at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:199)
at com.squareup.okhttp.Call.execute(Call.java:79)
at retrofit.client.OkClient.execute(OkClient.java:53)
at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:326)
... 7 more
Caused by: java.io.EOFException: \n not found: size=0 content=...
at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:190)
... 18 more

Now, with the real N5 really going through Charles AND with Charles allowing responses to come back through, the error does not manifest. That is a different result to the N5 emulator, where the error manifests whether responses blocked or not.

Just to be sure, to be sure, to be sure: Jesse you recently said:

"is there a missing CRLF (0e 0a) between the last header line and the response body?"

0e == Shift Out, while
0d == Carriage Return

OkHttp isn't erroneously looking for '0e 0a' when it should be looking for '0d 0a', is it?

@swankjesse

this is my log:

HTTP/1.1 200 OK
Date: Tue, 17 Mar 2015 09:41:25 GMT
Server: nginx/1.4.4
Content-Type: image/png
Content-Length: 12372
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 2592000
Cache-Control: public, max-age=31536000
Content-Disposition: inline; filename="5438e8e45cbe4.png"
Content-Transfer-Encoding: binary
ETag: "Fo36srH0XgSuMch_AL-fTQ5hR-eS"
X-Log: mc.g;IO
X-Reqid: -XoAAIGdAKsti8ET
X-Whom: nb263
X-Qiniu-Zone: 0
Age: 1
X-Via: 1.1 ych59:8104 (Cdn Cache Server V2.0), 1.1 qzh230:0 (Cdn Cache Server V2.0)
Connection: keep-alive

@swankjesse
it's same with you

@swankjesse
do you need other debug info?

@epint
how do you handle the problem(EOF) ?I happened so long time and make users unconfirtable experience.

@epint
do you give up the okhttp?or have someother method instead .?

@iceAnson can you run the program above and paste the complete hex response please?

@coreform does this occur on every URL you post to on the impacted N5?

@iceAnson for now one user is affected and were not handling it with hope that issue will be resolved. Otherwise we have some solutions in mind (i.e. fallback to some other client etc..) but none is implemented.

This must somehow be caused by the manufacturer modifications, from reading this thread - most of the affected devices are unlicensed chinese production. We are using OkHttp on a banking application and one client contacted the support line and we even managed to get the client with the phone to visit us and test it for 30 minutes (he did not have much time). Not a single http/https request worked through OkHttp on that application. He was using a ZOPO ZP998. It all failed with "java.io.EOFException: \n not found: size=17 content=03007fa861b9d60200000d0a300d0a0d0a...". I wish I had more time to debug.

How is it possible that the same application works on tens of thousands other devices but not on this one? Maybe the manufacturers are modifying the network stream or using some proxy? Or I don't know...

@DanielNovak even if this your point is correct, it has to be fixable in OkHttp since other clients (i.e. DefaultHttpClient) are not affected and http requests are working with same device, application and server.

@epint I think your bug in the emulator is different from the other bug. Your Nexus5 emulator gets an EOF on a stream of size 0; everyone else is seeing actually corrupted data in here. Wish I could get my hands on one of the impacted devices.

If any of you could run the code from this comment https://github.com/square/okhttp/issues/1114#issuecomment-82727393 and paste the resulting hex here, that'd be handy.

@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
that we're seeing the 0-byte issue intermittently on a Moto X 2014, Samsung
Galaxy S3 and LG G2. These just seem to be random devices from our test.

On Thu, Mar 19, 2015, 19:30 epint [email protected] wrote:

@swankjesse https://github.com/swankjesse your comment was probably
ment for @coreform https://github.com/coreform. We have a problem on
real device.

—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/1114#issuecomment-83704504.

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.

  • 0-byte responses, issue 1517. My hypothesis is that these are just badly-behaving webservers, or proxy servers or something. In OkHttp 2.3 we're now including more information about the connection when this problem occurs. This happens to normal devices, like your Moto X 2014.
  • corrupt responses, issue 1518. My hypothesis here is that we're doing something to trigger another bug, and ending up with a corrupt buffer of data.

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)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:210)
at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:830)
at com.squareup.okhttp.internal.http.HttpEngine.access$200(HttpEngine.java:95)
at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:823)
at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:684)
at com.squareup.okhttp.Call.getResponse(Call.java:272)
at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:228)
at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:199)
at com.squareup.okhttp.Call.execute(Call.java:79)
at com.uu.shit.connection.NetToJavaRequest.requestServer(NetToJavaRequest.java:27)
at com.uu.shit.connection.ConnectionTest.doOwnTest(ConnectionTest.java:23)
at com.uu.shit.MainTest.doTest(MainTest.java:71)
at com.uu.shit.ShitActivity$2$1.run(ShitActivity.java:87)
at java.lang.Thread.run(Thread.java:838)
Caused by: java.io.EOFException: \n not found: size=1460 content=446174653a205468752c203236204d617220323031352030343a30333a303120...

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)
03-31 13:29:45.255: I/RetrofitCallback(3661): error.getUrl() :http://
* error msg :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.
I also got Caused by: java.io.EOFException: \n not found:

After closer inspection I notices that after the status code, the server didn't gave a description.
Example:
HTTP/1.1 500 Internal server error
Content-Type: text/xml; charset=utf-8

But this is broken:
HTTP/1.1 500
Content-Type: text/xml; charset=utf-8

So in my example the (somewhat exotic) http server didn't return a reason after the status code.
RFC2616 defines a reason after the status, so in my case it's not a fault of the library.
But I thought I might mention it, it might help someone.

@christophesmet

Disable jit:
android:vmSafeMode="true"

see this:
https://github.com/square/okhttp/issues/1518

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
at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:154)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:189)
at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:101)
at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:676)
at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:426)
at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:371)
at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:466)
at retrofit.client.UrlConnectionClient.readResponse(UrlConnectionClient.java:73)
at retrofit.client.UrlConnectionClient.execute(UrlConnectionClient.java:38)
at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:321)
... 18 more

Currently getting the dreaded EOFException.

Running:
Samsung Galaxy Nexus
Android version 4.3

Project dependency:
compile 'com.squareup.retrofit:retrofit:1.9.0'

Adapter configuration:
RestAdapter adapter = new RestAdapter.Builder()
.setEndpoint(host)
.setRequestInterceptor(interceptor)
.setLogLevel(RestAdapter.LogLevel.FULL)
.setConverter( new GsonConverter(gson))
.build();

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 .addHeader("Accept-Encoding", "none") to above code I'm able to get the data I wanted. But the aim for me is to save the bandwidth, so this is only used as a temporary workaround.

To check if is header dependent error, I have also test with curl using same headers, and the result has been properly replied.

curl "http://sosu.qidian.com/ajax/search.ashx?method=Search&keyword=DD" -H "Accept: */*" -H "Referer: http://sosu.qidian.com/" -H "Connection: keep-alive" -H "Accept-Encoding: gzip" -H "User-Agent: okhttp/2.4.0" --compressed

GET /ajax/search.ashx?method=Search&keyword=DD HTTP/1.1
> Host: sosu.qidian.com
> Accept: */*
> Referer: http://sosu.qidian.com/
> Connection: keep-alive
> Accept-Encoding: gzip
> User-Agent: okhttp/2.4.0
>
< HTTP/1.1 200 OK
< Date: Fri, 24 Jul 2015 22:09:55 GMT
< Server: Microsoft-IIS/6.0
< X-Powered-By: ASP.NET
< X-AspNet-Version: 2.0.50727
< Set-Cookie: ASP.NET_SessionId=*hidden*; domain=.qidian.com; path=/; HttpOnly
< Set-Cookie: sosu_abtest=; expires=Thu, 23-Jul-2015 22:10:04 GMT; path=/
< Cache-Control: private
< Content-Type: text/plain; charset=utf-8
< Content-Encoding: gzip
< Transfer-Encoding: chunked
< X-Via: 1.1 czdx84:8107 (Cdn Cache Server V2.0), 1.1 ld15:6 (Cdn Cache Server V2.0)
< Connection: keep-alive
<
{ [5096 bytes data]

I've also created chunked gzip response using Apache and php, which okhttp had no problem:

=== BEGIN ===

<?php sleep(1);
for ($i = 0; $i < 80000; $i++) {
    echo mt_rand();
}
sleep(1);    ?>

=== END ===

.htaccess: SetOutputFilter DEFLATE

An ssl issue caused the no response bug with me.
For some reason, the error isn't show in the sslsocketfactory.
But doing the same call in python does show an ssl error.

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)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:211)
at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:917)
at com.squareup.okhttp.internal.http.HttpEngine.access$300(HttpEngine.java:95)
at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:902)
at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:760)
at com.squareup.okhttp.Call.getResponse(Call.java:274)
at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:230)
at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:201)
at com.squareup.okhttp.Call.execute(Call.java:81)
Caused by: java.io.EOFException: \n not found: size=0 content=...
at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:191)
... 17 more

OKHttp 2.4 doesn't work on some HUAWEI devices ..

eg: for android 4.2.2 (HUAWEI Y518-T00) wifi and 3G

compile 'com.squareup.okhttp:okhttp:2.4.0'
compile 'com.squareup.retrofit:retrofit:1.9.0'

Currently getting the dreaded EOFException:like this

2261-3324/com.bqs.wetime.fruits D/Retrofit﹕ java.io.IOException: unexpected end of stream on Connection{192.168.1.208:8080, proxy=DIRECT@ hostAddress=192.168.1.208 cipherSuite=none protocol=http/1.1} (recycle count=0)
            at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:211)
            at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
            at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:917)
            at com.squareup.okhttp.internal.http.HttpEngine.access$300(HttpEngine.java:95)
            at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:902)
            at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:760)
            at com.squareup.okhttp.Call.getResponse(Call.java:274)
            at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:230)
            at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:201)
            at com.squareup.okhttp.Call.execute(Call.java:81)
            at retrofit.client.OkClient.execute(OkClient.java:53)
            at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:326)
            at retrofit.RestAdapter$RestHandler.access$100(RestAdapter.java:220)
            at retrofit.RestAdapter$RestHandler$1.invoke(RestAdapter.java:265)
            at retrofit.RxSupport$2.run(RxSupport.java:55)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390)
            at java.util.concurrent.FutureTask.run(FutureTask.java:234)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
            at retrofit.Platform$Android$2$1.run(Platform.java:142)
            at java.lang.Thread.run(Thread.java:838)
     Caused by: java.io.EOFException: \n not found: size=9539 content=096f72672e737072696e676672616d65776f726b2e6a6462632e64617461736f...
            at okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
            at com.squareup.okhttp.internal.http.HttpConnection.readHeaders(HttpConnection.java:220)
            at com.squareup.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:199)
            at com.squareup.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
            at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:917)
            at com.squareup.okhttp.internal.http.HttpEngine.access$300(HttpEngine.java:95)
            at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:902)
            at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:760)
            at com.squareup.okhttp.Call.getResponse(Call.java:274)
            at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:230)
            at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:201)
            at com.squareup.okhttp.Call.execute(Call.java:81)
            at retrofit.client.OkClient.execute(OkClient.java:53)
            at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:326)
            at retrofit.RestAdapter$RestHandler.access$100(RestAdapter.java:220)
            at retrofit.RestAdapter$RestHandler$1.invoke(RestAdapter.java:265)
            at retrofit.RxSupport$2.run(RxSupport.java:55)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390)
            at java.util.concurrent.FutureTask.run(FutureTask.java:234)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
            at retrofit.Platform$Android$2$1.run(Platform.java:142)
            at java.lang.Thread.run(Thread.java:838)

Got the same error
ANDROID_VERSION=4.2.2
PHONE_MODEL=Quest 507

okhttp-2.4.0
okhttp-urlconnection-2.4.0
okio-1.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.

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

Was this page helpful?
0 / 5 - 0 ratings