HttpClient在Windows 2008 R2上未发送接受编码

Question

我有一个执行GET请求的.NET Core 2.0控制台应用程序。

似乎已发布的版本未Accept-Encoding在测试计算机上发送 用于压缩的标头，但在我的本地计算机上可用。

我找不到其他任何可能导致压缩失败的先决条件。两者都运行.NET Core 2.1.4 SDK。

我已经通过dotnet Console.dll在两种环境中运行对控制台应用程序进行了测试。

1. 在VS2017中发布
2. 转到输出文件夹并运行dotnet Console.dll。验证Fiddler中是否存在标题。
3. 复制整个输出文件夹并部署到服务器上
4. dotnet Console.dll再次运行，并使用Fiddler验证服务器上缺少标头。

我都尝试过HttpClient，RestSharp而且我很困惑。

进入与请求标头相呼应的页面的概念验证：

 var handler = new HttpClientHandler()
            {
                AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip
            };

 using (var client = new HttpClient(handler))
 {
      response = client.GetStringAsync("http://scooterlabs.com/echo").Result;
 }

本地环境（Win10）

GET http://scooterlabs.com/echo HTTP/1.1
Connection: Keep-Alive
Accept-Encoding: gzip, deflate
Host: scooterlabs.com

服务器（AWS上的Win2008 R2）

GET http://scooterlabs.com/echo HTTP/1.1
Connection: Keep-Alive
Host: scooterlabs.com

Answer 1

我最好的猜测是，这是因为 Windows 上的 HttpClient 默认使用的 WinHttp 库在Windows 8.1+ 之前的 Windows 版本上不支持gzip\deflate。当支持时 - WinHttp 还将设置 Accept-Encoding 标头。因此，在 Windows Server 2008 上，当 .NET 通过 WinHttp 路由请求时，它要么设置此选项并被忽略，要么检查此选项是否受支持，如果不支持，则不设置它。

如果您手动设置此标头（如client.DefaultRequestHeaders.AcceptEncoding.Add(new StringWithQualityHeaderValue("gzip"));） - 选项仍会被忽略，但标头会通过并且服务器返回压缩响应。如果支持 - WinHttp 将解压缩该响应并删除 Content-Encoding 标头，因此响应将解压缩到 .NET。如果不支持 - 响应将以压缩形式到达，如果您设置，.NET 本身将对其进行解压缩AutomaticDecompression。

总而言之，在 8.1 之前的 Windows 版本上，您似乎需要设置AutomaticDecompression相关Accept-Encoding标头才能按预期工作。