Android implementation of HTTPClient throwing up java.io.IOException #2651
Comments
|
@marek-safar is bugzilla still the right location for filing Xamarin bugs? |
|
From @marek-safar on January 23, 2019 8:7 No, use https://github.com/xamarin/xamarin-android/ for new issues |
|
@UnreachableCode are you using ModernHttpClient? I am confused on how The options for HTTP settings here under
None of the built-in options here use |
jonathanpeppers
added
the
need-info
|
Hi @jonathanpeppers. Not using ModernHttpClient. Just the default HttpClient setup. I had these settings:
Which lead to okhttp appearing in my stacktraces. However, I have now changed to this:
And I seem to no longer be receiving the error, leading me to believe it's not using okhttp anymore. |
|
@UnreachableCode I am wondering if you have some dependency using I would recommend using the Closing for now, but feel free to reopen/comment if you have another issue, thanks! |
|
@jonathanpeppers, Using Android HttpClient Implementation does throw Java exceptions instead of .NET exceptions. Similarly HttpClient iOS exception is System.Web.Exception. Is there any way that I could get the .NET Exceptions, so that I could use libraries like Polly to implement policies from .NET Standard project itself. I don't have any reference to Okhttp, but not sure how okhttp ends up in logs like the report above. |
|
@muhaym I am not familiar with Polly, but the exception will come through as Does Polly have a way to retry based on the type name? As a string? Not ideal, but a workaround for now. Can you file an issue on https://github.com/xamarin/xamarin-android/issues explaining the difference in exceptions you see in regular .NET vs iOS vs Android? |
|
@jonathanpeppers Thanks for the reply. Polly have a generic system to get the exception. Any way the matter of concern is not the ability to use Polly, but the ability to understand the core issue of exception from .NET Standard shared code. I have enough data of various exception for iOS and Android project from a live project. Should I file iOS and Android separately, or what will be the right place to discuss this issue? Ideally mapping to .NET Standard exception is what a developer can rely on, otherwise, the code duplication and writing separate interface for the httpclient for native platforms are double efforts of the same code. |
|
It seemed like iOS you are getting |
|
Yes, I'll proceed with an issue in this repo. |
|
Since AndroidClientHandler is the default HTTP handler in Xamarin Forms projects, it's at least interesting there is no reference in the documentation about native Java exceptions bubbling up. This was a big surprise to me when some devices like the Samsung Galaxy S9 with Android 9 started showing up in AppCenter with crashes, specifically around public class WorkaroundAndroidClientHandler : AndroidClientHandler
{
public WorkaroundAndroidClientHandler()
{
this.AutomaticDecompression = System.Net.DecompressionMethods.GZip | System.Net.DecompressionMethods.Deflate;
}
protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
// The native Android HTTP client handler bubbles up Java exceptions in contrast to the iOS native handler.
// See for instance https://github.com/xamarin/xamarin-android/issues/3216.
// We see this behavior on a Samsung 9 with Android 9.
// Remedy is to explicitly catch expected native network exceptions.
try
{
return await base.SendAsync(request, cancellationToken).ConfigureAwait(false);
}
catch (Java.Net.SocketException ex)
{
throw new WebException($"Native SocketException on HTTP request: {ex.Message}", ex);
}
catch (Java.IO.IOException ex)
{
throw new WebException($"Native IOException on HTTP request: {ex.Message}", ex);
}
catch (Java.Lang.Exception ex)
{
throw new WebException($"Native Exception on HTTP request: {ex.Message}", ex);
}
}
} |
ghost
locked as resolved and limited conversation to collaborators
From @UnreachableCode on January 17, 2019 16:54
I believe this relates to the bug detailed in Xamarin's old Bugzilla:
https://bugzilla.xamarin.com/show_bug.cgi?id=41100
and is also similar to the issue discussed here:
square/okhttp#1517
Here is the main stacktrace of my issue:
LoginProvider+d__1.MoveNext () C:\source\repos{MyApp}{MyApp}{MyApp}\Services\LoginProvider.cs:35
java.io.IOException: unexpected end of stream on Connection{testclarity.i-menzies.com:443, proxy=DIRECT@ hostAddress=62.244.173.166 cipherSuite=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 protocol=http/1.1} (recycle count=0)
com.android.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:210)
com.android.okhttp.internal.http.HttpTransport.readResponseHeaders(HttpTransport.java:80)
com.android.okhttp.internal.http.HttpEngine.readNetworkResponse(HttpEngine.java:905)
com.android.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:789)
com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:443)
com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:388)
com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:501)
com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getResponseCode(DelegatingHttpsURLConnection.java:105)
com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:25)
Caused by: java.io.EOFException: \n not found: size=0 content=...
com.android.okhttp.okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:200)
com.android.okhttp.internal.http.HttpConnection.readResponse(HttpConnection.java:191)
I have tried setting the connection closed header and setting chunked transfer encoding but neither of these fixes work. I would try to set the OkHTTP.setRetryOnConnectionFailure(true) but I don't think there is a way to do this in the referenced Java source.
Copied from original issue: dotnet/standard#1055
The text was updated successfully, but these errors were encountered: