如何使用 Dot-NET HttpClient 获取完整的 WWW-Authenticate 标头？

Question

设想

我正在开发适用于 Windows Phone 8 的 Web 程序（我认为这并不重要）并使用Microsoft HTTP 客户端库

问题

当用户尝试获取 URL 时，我需要知道当响应是 401 时需要什么类型的身份验证。如果是 NTLM、Basic、Digest 等，这很容易；所有支持的WinHTTP方案。您可以使用以下代码来获取 URL：

HttpResponseMessage response;
using (var httpClient = new HttpClient(httpHandler))
{
     HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Get, authenticationUri);
     response = await httpClient.SendAsync(request, _cancelTokenSource.Token);
}

检查需要哪种身份验证的最简单方法是使用该Headers.WwwAuthenticate.Contains方法，例如检查是否NTLM需要方案：

string scheme = "NTLM";
bool requiredScheme = response.Headers.WwwAuthenticate.Contains(new System.Net.Http.Headers.AuthenticationHeaderValue(scheme));

如果scheme = "Bearer"然后它总是给假。

获取响应头

以下是在尝试访问需要Azure Active Directory身份验证的服务器时获得的。

杰森 Chrome 应用程序

使用Jason Chrome App 从网络服务器获取响应标头，我收到：

Pragma: no-cache
Date: Fri, 10 Oct 2014 11:39:02 GMT
WWW-Authenticate: Bearer authorization_uri="https://login.windows.net/common",
    error="invalid_token", 
    error_description="The access token is missing", 
    NTLM
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Expires: -1
Cache-Control: no-cache
Content-Length: 0
X-UA-Compatible: IE=EmulateIE7

点网 Http 客户端

使用 HttpClient System.Net.Http.HttpResponseMessage( response) 给出：

StatusCode: 401, ReasonPhrase: 'Unauthorized', Version: 0.0, Content: System.Net.Http.StreamContent, Headers:
    {
      Server: Microsoft-IIS/7.5
      WWW-Authenticate: NTLM
      X-Powered-By: ASP.NET
      X-UA-Compatible: IE=EmulateIE7
      Date: Fri, 10 Oct 2014 11:25:04 GMT
      Content-Length: 1293
      Content-Type: text/html
    }

WWW-认证比较

根据以上结果，可以进行以下比较。

杰森 Chrome 应用程序

Bearer authorization_uri="https://login.windows.net/common", error="invalid_token", error_description="访问令牌丢失",

NTLM

点网 Http 客户端

NTLM

承载部分被 Http 客户端丢弃（或者这可能是 的限制HttpResponseMessage），只剩下 NTLM 身份验证。

题

我如何或在何处使用 Dot-NET HttpClient 获取完整的 WWW-Authenticate 标头以显示所有方案及其内容？这个例子是特定于 Bearer 的；但是，也存在其他（自定义）方案。

有任何想法吗？

---

额外的

即使在Windows.Web.Http.HttpClient上，同样的问题似乎仍然存在