I just noticed that using the .NET HttpWebRequest, I wasn't getting gzip'd contents back from the server (running nginx 0.8.52). Testing with curl, I verified that gzip was set up properly server-side, then dug into the issue with the VS debugger.
The culprit turns out to be how the Accept-Encoding header field is generated: if I set
request.AutomaticDecompression = DecompressionMethods.GZip |
DecompressionMethods.Deflate`
I get the following header:
`Accept-Encoding: gzip, deflate,gzip, deflate`.
If I set
request.AutomaticDecompression = DecompressionMethods.GZip;
I get
Accept-Encoding: gzip,gzip
I haven't checked what the HTTP specification says, but nginx ought to handle the situation, but instead it returns Vary: Accept-Encoding back. On the other hand, the Accept-Encoding header generated by HttpWebRequest definitely doesn't look right, and seems like a bug to me.
If I don't specify AutomaticDecompression and manually set the Accept-Encoding header, I get gzip'd content back, but HttpWebRequest seems to be pretty dumb, and doesn't decode the compressed stream (I guess it relies on an internal IsCompressed flag rather than parsing the response headers).
Any suggestions?
It should be noted that there's authentication involved; I've just found out that HttpWebRequest initially does a request without including the supplied credentials. For this request, the Accept-Encoding header is specified correctly. The duplication occurs after getting the 401 server response and re-doing the request with credentials.
I posted a Microsoft Connect bug report.
Seems to be a bug alright. Possible workarounds:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With