EOF Exception Android API 14+ , URLConnection

[GoogleCodeExporter]

Version of google-http-java-client (e.g. 1.5.0-beta)?
1.13.1-beta

Java environment (e.g. Java 6, Android 2.3, App Engine)?
Java 6, Android 4.X (Galaxy Nexus, Nexus 4, Nexus 7, Samsung S2) (Real devices 
NOT AVD).

Describe the problem.

Connection spoiling the header by leaving an old connection open. See attached 
forum post:
https://groups.google.com/forum/?fromgroups=#!topic/android-developers/e_FExl6jl
90

This is a sporadic bug, but "looks" like the connection terminated the 
connection randomly when it appears that the old connection is not "cleaned" 
properly.

How would you expect it to be fixed?

As mentioned in the forum post I am fixing the request with the following 
method when creating the request.

public static void tryToFixNetHttpRequest(final HttpHeaders headers)
{
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH)
            try
            {
                headers.set("Connection", "close");
            }
            catch (Exception e)
            {
            }
}

So far I am yet to see the error again. We can of course use this as a work 
around on android, but a better solution would be more appropriate. 

Original issue reported on code.google.com by chris.mark.jenkins@gmail.com on 27 Mar 2013 at 3:55

[GoogleCodeExporter]

I seem to only be getting this on POST requests and I think someone also 
mentioned this in the link mentioned above. 

Original comment by dorian.c...@googlemail.com on 27 Mar 2013 at 3:58

[GoogleCodeExporter]

Im getting this on a Nexus 4 running 4.2.2

Original comment by dorian.c...@googlemail.com on 28 Mar 2013 at 11:22

[GoogleCodeExporter]

The fix works but means the fix for this 
https://code.google.com/p/android/issues/detail?id=29509 bug cannot be 
implemented. When a carrier uses a **proxy** for network data and an **https** 
call is made over **3g** the socket is closed automatically using 
HttpUrlConnection. It seems JellyBean + HttpUrlConnection is not a happy bunny. 
:(

Original comment by dorian.c...@googlemail.com on 8 Apr 2013 at 10:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Still getting this compiling with android 4.4, so this has not been fixed.

And yes, seems to only work on POST requests.  In particular, if prior GET 
requests are issued with keep-alive connections, a POST request, after writing 
any data, will raise an EOF exception when trying to read the response headers.

This can be avoided by setting the connection to close on both the GET and POST 
requests.  But as was pointed out, this conflicts with another issue.

Original comment by mbar...@secureapps.us on 14 Nov 2013 at 12:48

[GoogleCodeExporter]

I think u should integrate httpclient .http://hc.apache.org/httpclient-3.x/

Original comment by gshi...@quikr.com on 14 Nov 2013 at 6:15

[GoogleCodeExporter]

This seems to be specific to the underlying java.net.HttpURLConnection. Unlike 
#5, I can not reproduce this issue on Android 4.4 API 19 (KitKat). Perhaps 
there are other issues involved which cause similar symptoms?

I am able to reproduce this 100% of the time on Android 4.3 API 18 (JB MR2) by 
sending a POST request and then idling the application for 10 minutes. This 
idle duration depends on the server's keepalive timeout. After a sufficiently 
long idle period, the next 2-4 POST requests fail with EOFExceptions before 
requests begin to work again.

Calling HttpURLConnection's setRequestProperty("Connection", "close") prevents 
this bug from happening.

Original comment by james.w...@gmail.com on 21 May 2014 at 5:28

[GoogleCodeExporter]

I was able to work around this problem using a retry mechanism. The trick is to 
ensure that the number of retries corresponds with the "http.maxConnections" 
system property. I shared the code here: 
http://stackoverflow.com/a/23795099/204480

Original comment by james.w...@gmail.com on 22 May 2014 at 1:14

[GoogleCodeExporter]

I had this behavior on several Devices from Samsung. HTC, Asus and LG didn't 
have this problem. All Devices are 4.1.2 and above.

The workaround from the OP saved me. Thanks a lot.

Original comment by grob....@gmail.com on 30 Jul 2014 at 5:04