2013-02-08 4 views
3

У меня есть NSURLConnection и в didReceiveResponse Я проверяю [response expectedContentLength] и получаю действительно большие значения, такие как 18446744073709551615. Правильно это не так. Загрузка составляет около 3 килобайт, и когда я ожидаю тот же запрос в скрипаче, я вижу (правильный) заголовок длины контента в ответе около 3 килобайт.Почему мой NSURLConnection сообщает о некорректном ожиданииContentLength

+0

Вы используете этот 'Accept-Encoding: gzip' в своем запросе? Возможно, вы можете отредактировать свой вопрос, чтобы поделиться своим кодом, который формулирует запрос (если вы делаете что-либо с запросом). И, если хотите, URL-адрес тоже. – Rob

+0

@Rob Я не использую accept-encoding: gzip в моем запросе. На самом деле, я * попытался * установить заголовок accept-encoding в пустую строку, чтобы сервер не использовал gzip, но это не имело никакого эффекта. Я не могу поделиться URL-адресом, так как это клиентский API, но похоже, что их сервер всегда gzips-ответ, поэтому то, что я пытаюсь сделать, не будет работать. – xdumaine

+0

Понял. Я (как вы, я уверен), вырыл вокруг, но не смог найти. Сожалею. Удачи. – Rob

ответ

2

Ответ, связанный с комментариями, состоит в том, что это потому, что результат кодируется gzip. Как ни странно, значение для expectedContentLength кажется нежелательным, и ему нельзя доверять. Если результат кодируется gzip, то NSURLConnection не может правильно определить размер некодированного результата.

3

Чтобы избежать этой проблемы, установите поле заголовка «Accept-Encoding» в значение @ «gzip; q = 0». который сообщает серверу, что вы не принимаете gzip, и по возможности отправите несжатый файл.

+0

См. Комментарии к вопросу. Я попробовал это, и этот конкретный сервер не принимает его. – xdumaine

+0

работал для меня :) – Leena

+0

Выше не работало для меня, хотя использовалось значение 'identity' для' Accept-Encoding'. – Rob