Okhttp: java.net.ProtocolException: Unexpected status line: '���� HTTP/1.1 200 OK

[justingboy]

java.net.ProtocolException: Unexpected status line: '���� HTTP/1.1 200 OK
at com.squareup.okhttp.internal.http.StatusLine.parse(StatusLine.java:54)
at com.squareup.okhttp.internal.http.Http1xStream.readResponse(Http1xStream.java:186)
at com.squareup.okhttp.internal.http.Http1xStream.readResponseHeaders(Http1xStream.java:127)
at com.squareup.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:737)
at com.squareup.okhttp.internal.http.HttpEngine.access$200(HttpEngine.java:87)
at com.squareup.okhttp.internal.http.HttpEngine$NetworkInterceptorChain.proceed(HttpEngine.java:722)
at com.squareup.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:576)
at com.squareup.okhttp.Call.getResponse(Call.java:287)
at com.squareup.okhttp.Call$ApplicationInterceptorChain.proceed(Call.java:243)
at com.squareup.okhttp.Call.getResponseWithInterceptorChain(Call.java:205)
at com.squareup.okhttp.Call.access$100(Call.java:35)
at com.squareup.okhttp.Call$AsyncCall.execute(Call.java:171)
at com.squareup.okhttp.internal.NamedRunnable.run(NamedRunnable.java:33)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:833)

[swankjesse]

Most likely the preceding response was malformed. You should tell the web server’s administrator to fix this.

Work-around by disabling connection pooling on requests to this host. The easiest way is with this request header:

Connection: close

[yschimke]

@justingboy closing this out, if the suggested fix doesn't work for you, let us know. Consider asking this and answering it on stackoverflow and I'll upvote both.

[15characterlimi]

FYI I've seen the same behavior when a HttpURLConnection was accessed from more than one thread; I'm guessing that Call is not thread safe either and can encounter the same behavior.

The underlying issue (at least in OkHttp 2.7.5's HttpURLConnectionImpl) is that thread unsafe access can lead to the same Buffer / same underlying Segment from the SegmentPool being accessed from more than one thread without safe (in terms of the memory model) hand-over, which can lead to the above behavior when thread A updates Segment.{data,limit,pos} but thread B sees only some of those updates.

[qyzhaojinxi]

Is this the only way to solve this problem? set connection as close in request header?