Okhttp: java.io.IOException: unexpected end of stream on okhttp3.Address@###

[masztalski]

2147 - in previous version there was also this issue and was apparently not resolved

While I am trying to connect to one of webservices used in my app on first attempt I get mentioned in title error, then after retry I got correct data.
My configuration of okHttpClient:

    @Provides
    @Singleton
    HttpLoggingInterceptor providesHttpLoggingInterceptor() {
        HttpLoggingInterceptor interceptor = new HttpLoggingInterceptor();
        interceptor.setLevel(HttpLoggingInterceptor.Level.BODY);
        return interceptor;
    }

    @Provides
    @Singleton
    StethoInterceptor providesStethoInterceptor(){
        return new StethoInterceptor();
    }

    @Provides
    @Singleton
    OkHttpClient providesOKClient(HttpLoggingInterceptor interceptor, StethoInterceptor stethoInterceptor) {
        return new OkHttpClient.Builder()
                .addInterceptor(interceptor)
                .addNetworkInterceptor(stethoInterceptor)
                .retryOnConnectionFailure(true)
                .connectTimeout(15, TimeUnit.SECONDS)
                .readTimeout(20, TimeUnit.SECONDS)
                .build();
    }

In the attachment there is screenshot from Stetho showing the situation and addreses I try to connect with.

Calls are made with Retrofit 2 - beta4 using Call asynchronous.

There is no rule when issue is occuring down, so I only leave it here.

[swankjesse]

Does the problem occur without Stetho? Looks like a Stetho bug at first glance.

[masztalski]

It is hard to say. Without and with Stetho in logcat there is no sign of this error. I noticed it while browsing Stetho so I post it. As I refered to another issue there was an identical error message directly indicating for okhttp3 class Address.

Currently it doesn't bother to my app, but I leave it to eventually investigation.

[swankjesse]

Got it. If you can come up with a way to reproduce, please do. I'm closing this for now since there's no obvious action for us to take.

[alanlee-gn]

I had a similar issue and resolved it by setting "Connection: close" in the header.

.header("Connection","close")

It seems "Keep-Alive" is added to the HTTP header by default and was causing an issue for me.

[balazsgerlei]

I also experience this. I too only see when using stetho with no sign in LogCat. I do not know if it is a bug with Stetho or OkHttp, and every time I saw this issue, the request than executed again successfully. Still weird though. Any ideas?

[alanlee-gn]

I don't think it is a bug in Stetho but assuming some issue with the established connection as that is what the Exception is telling us. Perhaps the server is closing the connection without honoring the keep alive request in some cases. With the server I'm testing, number of Exception I get keeps changing. Sometimes no exception at all.
I ended up removing _.header("Connection","close")_ to have keep alive working when there is no Exception thrown. The exception is just a internal connection check which fails fast so I'm just ignoring it for now.

[balazsgerlei]

But if it's not a bug with stetho, than how come the OkHttp LoggingInterceptor does not log the two requests?

[alanlee-gn]

@balazsgerlei Sorry. I'm just a mere user of both the libraries. I'm guessing a bit here but base on what I understand _HttpLoggingInterceptor_ only logs HTTP request and response. IOException is related to lower level connection which sits below HTTP. I would guess it is out of scope of the HttpLoggingIntereceptor. Also OkHttp does a retry and eventually would log both the HTTP request and HTTP response so nothing missing really. Please note that retry from the IOException would not be a HTTP retry as the library should find that there is an issue with the keep alive connection and merely tries to establish the connection again to send the HTTP request.

[dimsuz]

I started getting this exception logged immediately after we turned on gzip compression on server (running django). Not using Stetho.

It behaves similarly as described above: sends the request, logs an exception, sends it once more, then it succeeds.

[whalemare]

In my case, it`s been server-side error, not client.
Just wrote backend-guys about it and was waiting for a fixes:)

[dimsuz]

@whalemare do you have any details about what exactly was wrong on server-side?

[whalemare]

@dimsuz our nginx cached large responses into local folder /tmp/cache/nginx/some-cache-folder.
This some-cache-folder has incorrect access rights and nginx close connectiond immediatly, when ended its inner buffer, without save responses into folder. So magic trick)

[datvong-wm]

Got the same error. Turns out turning off BODY logging fixed it for us.

interceptor.setLevel(HttpLoggingInterceptor.Level.NONE);