Почему приходит неполная станица при иcпользовании curl + proxy?
Знатоки протокола HTTP, помогите с проблемой!
Использую curl (в PHP) через прокси (доступа к прокси нет) для получения контента сайта (прокси HTTP). Очень часто приходят страницы неполные, обрываются на полутеге (например ...<p class="myclasдальше контент заканчивается). Закономерностей когда и как оборвется контент нет. Притом если получать не через прокси - проблемы нет. Искал решения в интернете, находил следующие варианты решений:
1) Версию curl обновлял до 7.36 - не помогло.
2) Отправлял заголовок "Expect: " - не помогло.
3) Таймаут ставил в 0 - не помогло.
4) Выставлял опцию CURLOPT_HTTP_VERSION в CURL_HTTP_VERSION_1_0 - если ответ приходит формате HTTP 1.1 то все равно обрывается.
5) Получал контент в обход CURLOPT_RETURNTRANSFER = 1 через ob_start и так далее - не помогло.
6) CURLOPT_HTTP_TRANSFER_DECODING = 0 и CURLOPT_HTTP_CONTENT_DECODING = 0 - не помогло.
Если включать режим VERBOSE в curl, то на проблемных страницах пишет
...
nread <= 0, server closed connection, bailing
curl: (18) transfer closed with outstanding read data remaining
...
Также проблема наблюдается только при Transfer-Encoding: chunked. Наблюдается на очень многих сайтах.
Как все-таки получить контент полностью, или, если это невозможно, как определить что контент пришел неполный?
в общем, практически каждый док имеет html и body закрывающие теги, вот по ним и определяйте
если их нет - см. что там в RSS или что там еще можно скачивать
Запросы на самые разные сайта, от некоторых очень часто такие страницы идут, от других почти никогда. Если отключить прокси, страницы всегда корректны с любых сайтов.
iva3682: В данном случае прокси - это третья сила, на которую ты, по твоим словам, влияния не имеешь. Ты им не управляешь и он явно сбоит. 1) Отключи и не используй проксирование. 2) Обратись к админу прокси-сервера, опиши проблему.
Павел Волынцев: Дело в том что используются самые разные прокси (платные - бесплатные) из разных источников. Притом чем прокси "бесплатнее", тем сильнее это выражено. Можно ли как-то тогда абсолютно точно определить что контент оборвался при получении ответа?
Данная ситуация обрабатывается тут - https://github.com/bagder/curl/blob/c5d060cab47037... Может поможет правка исходников cUrl (чтобы выкидывал ошибку или предупреждение какое), но не будет ли "ложных" срабатываний?
iva3682: Нет там никакой ошибки снаружи. Это в прокси в логах можно только увидеть. Причины разные: некуда сохранять проксируемые страницы, жёсткие таймауты. Используй хорошие надёжные платные прокси.
Можно ли определить, что контент оборвался? А ты для чего используешь скачиваемые страницы? Парсишь что-то?
Павел Волынцев: пока только есть этот вариант (по закрывающим тегам типа body или html), но хотелось бы что-то более надежного, потому что если в ответ придет json или просто текст?
dimonchik2013: вариант в gzip рассматривался, но тоже есть минусы:
1. Что если сервер не поддерживает gzip? В ответ придет неза`gzip`ованная строка .Проблема остается актуальной
2. При варианте с gzip при обрыве контента и при распаковке строки тело ответа будет пустым. Но как проверить что ответ должен был быть вообще? Сервер всегда отправляет Content-Length: 0 в случае отправки только заголовков?
3. gzip все-таки не желателен, так как приходится расходовать ресурсы ЦП на распаковку. Но пока это самый лучший вариант решения данной проблемы(((
2. тестируйте ))) 3. пустяки, если, конечно, у вас там не ARM из первого Нексуса 1.вопрос интересный, могу порекомендовать перепроверять каким-нибудь head, вообще я не представляю ситуации,окромя сканирования уязвимостей, когда тело ответа будет нулевым, если страница должна возвращаться
ну и хороший совет - поддержание актуальной базы прокси, не смотреть на них кажый день как на новые
Средний
Простой
