-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Description
The current .NET Core code is behaving differently than .NET Framework when exceptions are thrown in a user-provided callback for the HttpClient ServerCertificateCustomValidationCallback.
In .NET Framework, any exception bubbling out of a user-provided callback is trapped, saved, and placed as an inner exception to the main HttpRequestException that is thrown. This is the current behavior of HttpClient on .NET Framework. Even for HttpWebRequest on .NET Framework, the exception is placed as an inner exception to the top-level WebException.
Currently, .NET Core is throwing a raw exception from the callback and propagating it as a top-level exception for HttpClient APIs. This bad pattern started with WinHttpHandler when I introduced (unknowingly) the bug. The behavior was then copied to the *Nix version.
This current test is therefore invalid:
[Fact]
public async Task UseCallback_CallbackThrowsException_ExceptionPropagates()
{
// ...
var handler = new HttpClientHandler();
using (var client = new HttpClient(handler))
{
var e = new DivideByZeroException();
handler.ServerCertificateCustomValidationCallback = delegate { throw e; };
Assert.Same(e, await Assert.ThrowsAsync<DivideByZeroException>(() => client.GetAsync(Configuration.Http.SecureRemoteEchoServer)));
}
}In my PR dotnet/corefx#21905 implementing ServerCertificateCustomValidationCallback for UWP, I have revised this test and disabled it on all platforms except UAP.