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 ()
Version: XI 9.10 (C8)
Hardware: PC Mac OS
: --- normal
Target Milestone: Future Cycle (TBD)
Assignee: Bugzilla
Depends on:
Reported: 2016-06-10 13:04 UTC by Martin Nygren
Modified: 2016-06-14 02:32 UTC (History)
3 users (show)

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

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

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

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

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

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

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 Team, assistant) 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.


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 Team, assistant) 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 Team, assistant) 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 Team, assistant) 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 ***