为什么我的 NSURLConnection 报告不正确的 expectedContentLength答案

【问题标题】：Why does my NSURLConnection report an incorrect expectedContentLength为什么我的 NSURLConnection 报告不正确的 expectedContentLength
【发布时间】：2013-02-08 15:16:07
【问题描述】：

我有一个 NSURLConnection 并且在 didReceiveResponse 中我正在检查 [response expectedContentLength] 并获得非常大的值，例如 18446744073709551615。这不可能是正确的。下载大约 3k 字节，当我在提琴手中期待相同的请求时，我在大约 3k 字节的响应中看到（正确的）内容长度标头。

【问题讨论】：

您是否在请求中使用了Accept-Encoding: gzip？也许您可以编辑您的问题以共享您制定请求的代码（如果您正在对请求执行任何操作）。而且，如果您愿意，也可以提供 URL。
@Rob 我没有在我的请求中使用接受编码：gzip。事实上，我尝试将accept-encoding标头设置为空字符串，以防止服务器使用gzip，但没有任何效果。我无法共享 URL，因为它是客户 API，但看起来他们的服务器总是 gzip 响应，所以我尝试做的不会工作。
明白。我（和你一样，我敢肯定）四处寻找解决方法，但找不到任何解决方法。对不起。祝你好运。
你能分享一下HTTP响应头吗？如果您在 Fiddler 的工具栏中设置了 DECODE 选项，问题会消失吗？

标签： ios objective-c

【解决方案1】：

为避免此问题，请将标头字段“Accept-Encoding”设置为@“gzip;q=0”。告诉服务器您不接受 gzip，如果可能，将发送未压缩的。

【讨论】：

查看问题上的 cmets。我试过了，这个特定的服务器不接受它。
上述方法对我不起作用，尽管使用 identity 的值代替 Accept-Encoding 确实有效。

【解决方案2】：

与 cmets 相关的答案是因为结果是 gzip 编码的。奇怪的是，expectedContentLength 的值似乎是垃圾，不能被信任。如果结果是 gzip 编码的，那么NSURLConnection 无法正确确定未编码结果的大小。

【讨论】：