Bug 41699 - HttpClient PostAsync fails with an IP Address as the Host Part of the URL.
Summary: HttpClient PostAsync fails with an IP Address as the Host Part of the URL.
Status: RESOLVED DUPLICATE of bug 41782
Alias: None
Product: iOS
Classification: Xamarin
Component: General (show other bugs)
Version: XI 9.10 (C8)
Hardware: PC Mac OS
: --- normal
Target Milestone: Future Cycle (TBD)
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-06-10 13:04 UTC by Martin Nygren
Modified: 2016-06-14 02:32 UTC (History)
3 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Invalid test case (works correctly) (10.53 KB, application/zip)
2016-06-14 00:15 UTC, Brendan Zagaeski (Xamarin Support)
Details

Description Martin Nygren 2016-06-10 13:04:11 UTC
Something like this worked fine but fails after upgrading to Xamarin.iOS 9.8.0.32

var httpClient = new HttpClient(messageHandler);
httpClient.Timeout = TimeSpan.FromSeconds (20);
var emptyContent = new StringContent("{}", Encoding.UTF8, "application/json");
await httpClient.PostAsync("https://68.193.132.226:443/api_current/", emptyContent);

In version 9.8.0.32 the above code raises System.Net.WebException with status NameResolutionFailure.
Comment 1 Alex Soto [MSFT] 2016-06-11 06:59:47 UTC
Hello

I tested the following code but could not reproduce your issue

> var httpClient = new HttpClient ();
> httpClient.Timeout = TimeSpan.FromSeconds (20);
> var content = new StringContent ("{\"id\": 110}", Encoding.UTF8, "application/json");
> var post = await httpClient.PostAsync ("https://jsonplaceholder.typicode.com/posts", content);

Please include a test case (to reproduce), your full build logs, crash reports (if any) and all version informations.

The easiest way to get exact version information is to use the 
"Xamarin Studio" menu, "About Xamarin Studio" item, "Show Details" 
button and copy/paste the version informations (you can use the 
"Copy Information" button).
Comment 2 Martin Nygren 2016-06-11 09:15:59 UTC
Alex, the bug occurs if you try a URL with an IP address that is not on your internal network.

See this discussion, http://forums.xamarin.com/discussion/comment/202428#Comment_202428
Comment 3 Brendan Zagaeski (Xamarin Support) 2016-06-14 00:15:22 UTC
Created attachment 16307 [details]
Invalid test case (works correctly)

Here is a complete zipped up test project that does _not_ hit the problem, so a bit more information will still be needed to replicate this issue.


But I do have an observation that might be an important clue about how to replicate the issue:


This _working_ test case includes an _insecure_ custom `ServicePointManager.ServerCertificateValidationCallback` that always returns `true`.  I had to do that because I didn't know of any existing sites where the TLS certificate includes a raw IP address as one of the allowed "Common Name" entries (see [1]).

[1] http://stackoverflow.com/questions/2043617/is-it-possible-to-have-ssl-certificate-for-ip-address-not-domain-name




## Next questions for users hitting this issue

1. If any user who is hitting this exception can attach (or paste) back the complete stack trace of the exception message, that would be good.  I am in particular curious to check if the name resolution failure is happening during TLS authentication (I suspect it is).


2. If any user who is hitting this exception can provide a sample IP address that is already set up with a TLS certificate that includes the raw IP address, that might cut down on a bit of back-and-forth and wait time on the further investigation of the bug.


3. Does disabling the new default "Apple TLS" implementation help:

Under "Project Options > iOS Build", change the "SSL/TLS implementation" setting back to the old default "Mono (TLS v1.0)".

Additional info from the release notes:

> By default your projects will now use the new Apple TLS stack which
> uses native code (better performance) and support the newest TLS 1.1
> and 1.2 standards. This is a change from previous preview releases of
> XI 9.8.

(https://developer.xamarin.com/releases/ios/xamarin.ios_9/xamarin.ios_9.8/)


4. Does the problem happen on both simulator and device, or only on device?  If it only happens on device, which device and iOS version are you using?


Thanks in advance!




## Next possible steps for Xamarin

If we can temporarily set up a raw static IP address that has a valid TLS certificate, we might be able to replicate the problem locally using that IP address.
Comment 4 Brendan Zagaeski (Xamarin Support) 2016-06-14 00:23:24 UTC
For question (2) for users, if you'd rather keep the IP address information private, feel free to send it by email to contact@xamarin.com, or you can file your own private bug report that includes your IP address and then mark it as a duplicate of this public bug.  (Private bug reports are only visible to the reporter of the bug and the Xamarin team, even after they are marked as duplicates.)
Comment 5 Brendan Zagaeski (Xamarin Support) 2016-06-14 01:02:30 UTC
## Update

After a bit more investigation, I now fairly strongly suspect that this is a duplicate of non-public Bug 41571, where certain IP addresses were seen to always produce the NameResolutionFailure error, with no involvement of TLS.

I will re-file Bug 41571 publicly for further tracking, and I will then update this bug with a link to the new public bug.
Comment 6 Brendan Zagaeski (Xamarin Support) 2016-06-14 02:32:33 UTC
I will tentatively mark this bug as a duplicate of the new public bug that is tracking the issue mentioned in Comment 5.  As discussed on the new public bug report, this issue affects certain IP addresses, but it is not yet clear if there is a rule or pattern about which particular IP addresses fail.  So if any users are willing to privately provide additional examples of IP addresses that fail, that could be helpful.  That said, the team does now have at least one example of a "bad" IP address to test against.  Thanks again!

*** This bug has been marked as a duplicate of bug 41782 ***

Note You need to log in before you can comment on or make changes to this bug.