为什么我的NSURLConnection报告的expectedContentLength不正确 [英] Why does my NSURLConnection report an incorrect expectedContentLength

问题描述

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

I have an NSURLConnection and in didReceiveResponse I'm checking [response expectedContentLength] and getting really large values like 18446744073709551615. There's no way this is correct. The download is about 3k bytes, and when I expect the same request in fiddler, I see a (correct) content length header in the response of about 3k bytes.

推荐答案

与评论相关的答案是因为结果是gzip编码的。奇怪的是， expectedContentLength 的值似乎是垃圾，并且不可信任。如果结果是gzip编码，则 NSURLConnection 无法正确确定未编码结果的大小。

The answer, related to the comments, is that it's because the result is gzip encoded. Oddly, the value for the expectedContentLength seems to be junk, and cannot be trusted. If the result is gzip encoded, then NSURLConnection cannot properly determine the size of the unencoded result.

这篇关于为什么我的NSURLConnection报告的expectedContentLength不正确的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！