Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
An update to the above issue, this issue exist only when we select Set SSL/TLS implementation to "AppleTLS", however its working fine if we select "Mono (TLS v1.0)".
The same exception happens for
> HttpWebRequest (TLSv1.2)TLSv1.0
except that in HttpClient case this is thrown from async code so this is not catch by the user code (it becomes an unhandled exception and crash the app).
The code must have changed from C8 where it worked previously.
@Martin, the above rings a bell ?
>>NOTE : This issue exist only on device and Its working fine on simulator.
An update to this issue. This issue occurs in simulator as well.
Steps to reproduce:
Download http client sample from : https://github.com/xamarin/private-samples/tree/master/HttpClient
Set HttpClient Impementation to Managed.
SSL/TLS impelementation to "AppleTLS"
Deploy app on simulator or device.
Click on HttpWebRequest (TLSv1.2)TLSv1.0.
There must be a connection failure.
Error : SecureChannelFailure(Unknown Secure transport 'Negotiation')
Click on HttpClient (TLSv1.2)TLSv1.0
App crashes with an unhandled exception.
>> ## Update to comment #0 and #1.
HttpClient (TLSv1.2)TLSv1.0 will give a crash, when HttpClientImplementation is set to "CFNetwork" and SSL/TLS implementation is set to "AppleTLS". HttpClient Implementation is not mentioned in comment#0 and comment #1.
## Crash log: https://gist.github.com/GouriKumari/d2e1df82fc14ce718ed45516f57c7599
## This issue occurs only on device and not on simulator
## This works with Cycle8 stable but crashes with cycle9
>>## Update to comment #3 and #2:
After discussing with 360L and verifying the issue locally, I confirmed that the test case reproduction mentioned in comment#3 and comment #2 is as expected with private sample "HttpClient" when HttpClient Implementation is set to "Managed" and SSL/TLS Implementation is set to "AppleTLS" and it shows the same behaviour with cycle8 and cycle9.
HttpWebRequest (TLSv1.2)TLSv1.0 will give a secure channel failure.
HttpClient (TLSv1.2)TLSv1.0 will give a crash
>> ## Conclusion:
Issue mentioned in comment #0 occurs only on device when HttpClientImplementation is set to "CFNetwork" and SSL/TLS implementation is set to "AppleTLS" and is working on simulator. This works with cycle8 stable build.
@Gouri this is quite confusing.
That's not a crash, it's the exception. However it shows that this is using HttpClientHandler  and *not* CFNetworkHandler. The later does not use AppleTLS (at least our code) nor the old managed provider - so results should be identical.
Without a build log there's no way to tell if what was build is the configuration you're describing - even if it's clearly not what was being executed .
Please whenever there's a crash on a device we *need*
- the full build log (not provided);
- the symbolicated crash report (not provided);
- the device logs that cover the time of the crash (not provided);
- the output of the application;
After reading comment #5, I think I owe an explanation.
>>@Gouri this is quite confusing.
I wasn't reporting anything new in comment #4 but was trying to provide additional info that Mohit missed in comment #0 and #1. Also, I was confirming the reason why it wasn't caught in our first regression pass.
1) Issue Mohit reported (TLSv1.2 request sent to TLSv1.0 server) occurs only when HttpClient Implementation is set to "CFNetwork" and SSL implementation is set to "AppleTLS". This is a negative testcase and details are provided below.
>> it shows that this is using HttpClientHandler  and *not* CFNetworkHandler. The >> later does not use AppleTLS (at least our code) nor the old managed provider - so >>results should be identical.
I understand that CFNetworkHandler is a wrapper around Apple's CFNetwork and uses native API and does not use AppleTLS (Martin's implementation) or managed provider. However, test cases were written and corrected in Cycle7 after discussing with Martin. There were negative test cases to check whether TLSv1.2 request sent to TLSv1.0 server work if Managed Handler+AppleTLS, CFNetWork+AppleTLS, NSUrlSession+AppleTLS are set. First case should fail , second and third should pass irrespective of SSL/TLS implementation set by user since Apple's native api is being used. This bug report reports CFNetwork+AppleTLS is throwing an unhandled exception on device which results the app to crash. This was working previously in cycle8 for both device/simulator and the same setting is working for simulator in cycle9.
>>That's not a crash, it's the exception.
The unhandled exception causes the app to crash on device. I mentioned stacktrace as crash log, sorry about that. But there is no change in stack trace file and application output file provided from comment #0. The only missing log is build output. @mohit360 or I will provide it on Monday.
>>Please whenever there's a crash on a device we *need*
>>- the full build log (not provided); (Will provide on Monday)
>>- the symbolicated crash report (not provided); (unhandled exception details provided in comment #0 and #4 , no symbolicated crash report generated.
>>- the device logs that cover the time of the crash (not provided); (there was an unhandled exception which resulted in the app to crash.
>>- the output of the application; (Provided in comment #0):https://gist.github.com/Mohit-Kheterpal/3e023c71617a49986b8ae38c05e55524
In all iOS bugs we do provide build log, test output and test environment details. Unhandled exception may not generate a symbolicated crash report, logs added in that case won't be symbolicated.
Below are few more information :
Run on Debug/Device configuration on iOS 10.2 device (iPhone 7)
Device Logs : https://gist.github.com/Mohit-Kheterpal/15a58db5a7167ade3997b0917a7a2106
Build output : https://gist.github.com/Mohit-Kheterpal/ec48d4f7df5325043effac2cdd16c856
Xcode Symbolicate logs : https://gist.github.com/Mohit-Kheterpal/9d07dc6239f1060afe3ec02c056e1eae
Cycle 8 Stable builds (Working Environment)
Device logs : https://gist.github.com/Mohit-Kheterpal/7b843b98c5252d29e82083b1ac577882
Build output : https://gist.github.com/Mohit-Kheterpal/8967057a292bdddced21c0f284ace585
Below is the testcase, expected, actual behaviour and build logs/symbolicated crash reports from Mohit.
1. Set HttpClient Implementation : Managed
SSL/TLS implementation : AppleTLS
Launch app on device and click on httpClient(TLSv1.2) TLSv1.0 to test whether TLSv1.2 request is expected by TLSv1.0 server.
It should return a message "Error : SecureChannelFailure(Unknown Secure transport 'Negotiation')" on device/simulator
An exception is raised on device and is reproducible continuously.
On simulator correct error message is received.
Build Log: https://gist.github.com/Mohit-Kheterpal/5067fe4e354907e9527c75ae680c7709
Xcode symbolicated logs: https://gist.github.com/Mohit-Kheterpal/63df029fbf98c3d0c25a39f51c3a2999
With cycle8 builds, httpClient(TLSv1.2) TLSv1.0. returns "Error : SecureChannelFailure(Unknown Secure transport 'Negotiation')" on device/simulator, which is the correct behaviour and there are no exceptions.
Setting CFNetwork caused similar exception (build logs and crash logs are mentioned in comment #7), but this is occurring only randomly.
## Test Env: https://gist.github.com/Mohit-Kheterpal/85e80cb498f2d3ddb89efe8e1e632e60
It looks like this is now throwing System.Net.Http.HttpRequestException (which looks more correct to me) instead of System.Net.WebException - probably caused by this commit:
We should update the sample to also expect this exception type.
Thanks Martin. After updating the sample to handle HttpRequestException correctly the issue is resolved. Closing this bug. Since this is a sample issue I am lowering the priority but the change needs to be documented.
Updated sample pull request:
As per comment 9, now httpclient sample throws exception System.Net.Http.HttpRequestException and its expected behaviour as shown in screencast : https://www.screencast.com/t/W89v3qpY7J
Hence closing this issue by marking it as Verified.