NSURLConnection, отказывающий под 10.5.7
Вы можете использовать этот CSS для «имитации» подчеркивания:
text-decoration: none;
border-bottom: 1px solid #000;
8 ответов
Я думаю, что ответ Юджина в этой ветке правильно описывает проблему; после некоторого тестирования я пришел к выводу, что, по-видимому, происходит следующее, с некоторыми подробностями, которые, надеюсь, помогут другим решить эту проблему:
Перенаправление URL-адресов будет периодически вызывать сбои. Это происходит как при синхронном, так и при асинхронном использовании NSURLConnection . Я создал тестовый проект для отслеживания этой ошибки, и этот сбой будет происходить постоянно (обычно между 25-500 итерациями). Выполнение того же теста на 10.5.6 или без перенаправления URL-адресов не завершится ошибкой (прогнал до 20 000 итераций).
Есть два возможных решения:
- Не использовать перенаправляющие URL-адреса:
Очевидно, это не всегда возможно, но если это известный URL, вы все равно можете использовать простые вызовы (например,stringWithContentsOfURL:), и это будет работать нормально. Деннис, в вашем случае правильный URL-адрес сервера -download.finance.yahoo.com, а неfinancial.yahoo.com, поэтому я считаю, что это решит вашу конкретную проблему. Используяcurl, вы можете увидеть, что при переходе по последнему адресу вы получаете перенаправление 301. - Используйте асинхронные вызовы и реализуйте
соединение: willSendRequest: redirectResponse:
Если вы реализуете даже Самая простая обработка этого метода делегата, кажется, все работает. Если вы опустите этот вызов (и, таким образом, позволите системе использовать его реализацию по умолчанию), вы получите сбой. Для базовой реализации просто верните переданный запрос:
Я бы посоветовал не использовать синхронные соединения URL. Это требует некоторой реструктуризации кода, но блокировать основной поток в сети - это действительно плохое поведение. (Предполагая, что вы делаете это в основном потоке.)
Кроме того, я предполагаю, что это код, который Apple планирует исключить или прекратить поддерживать, что может быть тем, что вы здесь видите.
Надеюсь, что это поможет ….
Мы наблюдаем ту же проблему при использовании нерекомендуемых stringWithContentsOfURL и sendSynchronousRequest (в разных местах). Мы видим тот же тип поведения; вызов может работать нормально для многих итераций, а затем будет случайным образом завершаться ошибкой (для идентичных запросов).
Учитывая, что синхронные вызовы построены на основе механизма async, нет причин, по которым эти вызовы все еще не должны работать должным образом. К сожалению, у нас пока нет решения.
Похоже, это связано с перенаправлениями. Мое приложение, загружающее около 500 мегабайт данных напрямую (несколько сотен отдельных файлов), не дает сбоев. Одно и то же приложение, загружающее меньший набор URL-адресов, все из которых перенаправляются, случайным образом выйдет из строя несколько раз именно в этой точке (перезапуск возобновляется, а перезапуск снова и снова фактически приведет к успешной загрузке).
РЕДАКТИРОВАТЬ: Кстати, предложение Колина по поводу повторная реализация перенаправления не работает для NSURLDownload :(.
EDIT2: Хорошо, похоже, это состояние гонки. Добавление cerr << "redirect" << endl; в обратном вызове "исправляет" это для меня с помощью NSURLDownload .
Я также видел точно такой же сбой в 10.5.7 в нескольких приложениях.
Учитывая, что реализация простейшего соединения: willSendRequest: redirectResponse: метод делегата будет решить проблему, я думаю, это может быть связано с радаром № 6700222 .
В Omni Group мы наблюдаем этот новый сбой в 10.5.7 во всех наших приложениях, использующих NSURL, также при асинхронном использовании (так что я думаю, что синхронность - отвлекающий маневр). У нас также было это в TextMate (предположительно в обновлении программного обеспечения).
Я зарегистрировал Radar 6932684 по этой проблеме, и если вы тоже это видите, я настоятельно рекомендую вам всем сообщить это, с любыми подробностями, которые вы сможете собрать.
Сбои в objc_msgSend обычно происходят из-за неправильного жизненного цикла объекта (т. Е. Объект был освобожден и ему отправляется сообщение).
Выполнить ваш код с NSZombieEnabled, чтобы выяснить, действительно ли это ваша проблема, и увидеть, какой объект выпускается раньше.
Что бы это ни стоило, похоже, что это исправлено в 10.5.8 --- но она была заменена новой ошибкой, которая добавляет тело ответа перенаправления к реальный ответ примерно в 2% случаев. (Легко воспроизвести, вращая -stringWithContentsOfURL :, но мы также видели это в дикой природе.) Об этой ошибке сообщается как радар № 7169953.