问题描述
我有一个可怕的时间解决此问题。我也有一个可怕的时间一致重现它从一个应用程序到另一个。
I am having a terrible time troubleshooting this issue. I'm also having a terrible time reproducing it consistently from one application to another.
在某些情况下，我似乎无法识别，使得PUT和使用的HttpClient导致以下异常POST调用。
Under certain circumstances, which I cannot seem to identify, making PUT and POST calls using the HttpClient results in the following exception.
发送请求时发生错误。
"An error occurred while sending the request."
内部异常：
基础连接已关闭：上一个发送发生意外的错误
Inner Exception:
"The underlying connection was closed: An unexpected error occurred on a send."
内部异常：
此操作无法在完成异步结果对象来完成。
Inner Exception:
"This operation cannot be performed on a completed asynchronous result object."
一切似乎都与HTTP工作，这只是发生在HTTPS。
Everything seems to work with HTTP, this only happens on HTTPS.
证书是有效的，但我已经尝试设置 ServicePointManager.ServerCertificateValidationCallback + =（发件人，证书，链，错误）=>真;
Certificates are valid, but I have tried setting the ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, errors) => true;
我已经尝试设置 client.DefaultRequestHeaders.ExpectContinue = FALSE;
我都试过了，什么似乎像一个亿，其他的事情，从头部，认证等。
I have tried, what seems like a million, other things ranging from headers, authentication, etc.
有没有人有任何想法，我还有什么可以检查，尽量等？
Does anyone have any idea what else I can check, try, etc?
code片断：
// this is my registration in my IoC container...
var handler = new HttpClientHandler
{
UseDefaultCredentials = true,
Credentials = CredentialCache.DefaultNetworkCredentials,
};
var client = HttpClientFactory.Create(handler);
client.BaseAddress = new Uri(Properties.Settings.Default.BaseUrl);
client.DefaultRequestHeaders.Add("X-CustomHeader", "value");
// _client is constructor injected into my class...
var response = await _client.PutAsJsonAsync("api/resource/" + id, model).ConfigureAwait(false);
response.EnsureSuccessStatusCode(); // <-- never executes...
更新：
如果我脱下ConfigureAwait（假），它工作正常。
If I take off the ConfigureAwait(false) it works fine.
请注意，这是一个WPF应用程序，具体而言，这是一个Visual Studio扩展。不过，我有一个ASP.NET MVC 4应用程序完全相同的问题，并且该应用程序不会调用.ConfigureAwait（假）;在所有...
Note, this is a WPF app, specifically, this is a Visual Studio extension. However, I do have an ASP.NET MVC 4 application with the exact same problem, and that application does not call .ConfigureAwait(false); at all...
更新2：
我更新了code段包括HttpClient的类的实例。未包含在code段的唯一的事情就是型号和声明。它应该是不相关的，因为它是一个序列化的类与所有自动属性，没有复杂的类型。
I updated the code snippet to include the instantiation of the HttpClient class. The only thing that is not included in the code snippet is the model type and declaration. It should be irrelevant, as it is a serializable class with all auto properties with no complex types.
更新3：
我不知道这是否是相关的，但我发现，看起来怪我一些东西。
I don't know if this is relevant, but I have found a few things which look weird to me.
在执行上面的code，提琴手，我得到一个401的POST，其次是2 CONNECT的这导致以下HTTP响应：
When executing the above code, in Fiddler, I get a 401 on the POST, followed by 2 CONNECT's which result in the following HTTP responses:
HTTP/1.1 200 Connection Established
Connection: close
更新4：
我改变了国际奥委会的注册code是这样的：
I changed my IoC registration code to be this:
var handler = new HttpClientHandler
{
UseDefaultCredentials = true,
Credentials = CredentialCache.DefaultCredentials,
};
var client = HttpClientFactory.Create(handler);
client.BaseAddress = new Uri(Properties.Settings.Default.BaseUrl);
client.DefaultRequestHeaders.Add("X-CustomHeader", "value");和现在它失败了，但是当我打开小提琴手，让它解密交通......它工作！
and now it fails, but when I open Fiddler and let it decrypt traffic ... it works!
更新5：
我相信这一定是服务器的问题，或证书的问题。什么检查从这里的任何提示将不胜AP preciated。证书是有效的，并从一个信任的CA颁发。
I believe this must be a server issue, or a cert issue. Any tips on what to check from here would be greatly appreciated. Certs are valid and issued from a trusted CA.
更新6：
更多调试和故障排除。该ServicePointManager CertificateValidationCallback被调用之前发生的异常。
More debugging and troubleshooting. The exception occurs before the ServicePointManager CertificateValidationCallback is invoked.
推荐答案
我只是做故障排除与HttpClient的一个类似的问题。原来我是在SSL握手，这引起HttpClient的无限期地锁定在接收SNI警告。尝试运行Wireshark的/ tcpdump的，看看你得到一个使用TLSv1无法识别名称的警告，或任何其他类型的握手警告。 HttpClient的似乎并没有处理这些正确基于我的测试。
I just got done troubleshooting a similar issue with HttpClient. It turns out I was receiving an SNI warning during the SSL handshake, which caused HttpClient to lock up indefinitely. Try running WireShark/tcpdump and see if you are getting a TLSv1 Unrecognized Name warning, or any other kind of handshake warning. HttpClient does not appear to handle these properly based on my tests.
这篇关于.NET 4.5 HttpClient的PUT或POST通过SSL总是失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！