.NET HttpWebRequest中的压缩(标题)错误?

sne*_*rch 8 .net httpwebrequest

我只是注意到使用.NET HttpWebRequest,我没有从服务器获取gzip的内容(运行nginx 0.8.52).使用curl进行测试,我验证了gzip是在服务器端正确设置的,然后用VS调试器挖掘问题.

罪魁祸首是如何Accept-Encoding生成标题字段:如果我设置

 request.AutomaticDecompression = DecompressionMethods.GZip | 
                                   DecompressionMethods.Deflate`
Run Code Online (Sandbox Code Playgroud)

我得到以下标题:

`Accept-Encoding: gzip, deflate,gzip, deflate`. 
Run Code Online (Sandbox Code Playgroud)

如果我订

request.AutomaticDecompression = DecompressionMethods.GZip; 
Run Code Online (Sandbox Code Playgroud)

我明白了

Accept-Encoding: gzip,gzip
Run Code Online (Sandbox Code Playgroud)

我没有检查HTTP规范说的是什么,但是nginx应该处理这种情况,而是返回它Vary: Accept-Encoding.另一方面,Accept-Encoding生成的标题HttpWebRequest肯定看起来不对,对我来说似乎是个错误.

如果我没有指定AutomaticDecompression并手动设置Accept-Encoding标题,我会重新获得gzip内容,但HttpWebRequest似乎非常愚蠢,并且不解码压缩流(我猜它依赖于内部IsCompressed标志而不是解析响应头).

有什么建议?

编辑:

应该注意的是,涉及到身份验证; 我刚刚发现,HttpWebRequest最初会在包含提供的凭据的情况下执行请求.对于此请求,Accept-Encoding正确指定了标头.获取401服务器响应并使用凭据重新执行请求后发生重复.

编辑2:

我发布了一个Microsoft Connect 错误报告.

sne*_*rch 4

看来是一个错误好吧。可能的解决方法:

  1. 不要使用AutomaticDecompression,手动设置“Accept-Encoding”标头字段,如果设置了“Content-Encoding”属性,则手动处理响应流的解压缩。
  2. 不要使用 Credentials 属性,而是手动构建 HTTP 授权标头。这消除了不必要的服务器往返并修复了标头字段重复错误。