Почему cURL возвращает "дополнительный материал не очень хорошо"?

Я пишу приложение Python, которое запрашивает API социальных сетей через cURL. Большинство различных запросов, которые я запрашиваю (Google+, Reddit, Twitter, Facebook и другие), жалуются cURL:

дополнительный материал не тонкий transfer.c: 1037: 0 0

Необычно, что при первом запуске приложения каждый ответ службы будет выдавать эту строку один или два раза. Через несколько минут линия появится несколько раз. Очевидно, что cURL идентифицирует то, что ему не нравится. Примерно через полчаса серверы начинают тайм-аут, и эта линия повторяется много десятков раз, поэтому она показывает реальную проблему.

Как я могу диагностировать это? Я попытался использовать Wireshark для захвата заголовков запросов и ответов для поиска аномалий, которые могут вызвать жалобу cURL, но для всей сложности Wireshark не существует способа изолировать и отображать только заголовки.

Вот соответствующая часть кода:

output = cStringIO.StringIO()
c = pycurl.Curl()
c.setopt(c.URL, url)
c.setopt(c.USERAGENT, 'Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0')
c.setopt(c.WRITEFUNCTION, output.write)
c.setopt(c.CONNECTTIMEOUT, 10) 
c.setopt(c.TIMEOUT, 15) 
c.setopt(c.FAILONERROR, True)
c.setopt(c.NOSIGNAL, 1)

try:
    c.perform()
    toReturn = output.getvalue()
    output.close()
    return toReturn

except pycurl.error, error:
    errno, errstr = error
    print 'The following cURL error occurred: ', errstr

Ответ 1

Я уверен, 99,99% на самом деле не в каких-либо HTTP-заголовках, но скорее печатается на stderr на libcurl. Возможно, это происходит в середине регистрации журналов, поэтому вы были смущены.

В любом случае, быстрый поиск "additional stuff not fine" curl transfer.c показал недавнее изменение в источнике, где описание:

Curl_readwrite: удалить вывод отладки

Текст "дополнительный материал не тонкий" был добавлен для целей отладки когда-то, но это никому не помогает, и почему-то некоторые Linux-дистрибутивы предоставляют свои libcurls, созданные с помощью отладочной информации, все еще настоящее и, следовательно, (слишком много) пользователей получают эту информацию.

Итак, это в основном безвредно, и единственная причина, по которой вы это видите, - это получить сборку libcurl (возможно, из вашего дистрибутива linux), в которой включено полное ведение журнала отладки (несмотря на то, что автор curl что плохая идея). Таким образом, у вас есть три варианта:

Игнорировать его.
Перейдите к более поздней версии libcurl.
Восстановить libcurl без информации об отладке.

Вы можете посмотреть источник libcurl для transfer.c (как указано выше), чтобы попытаться понять, о чем жалуется curl, и, возможно, искать потоки в списке рассылки примерно в одно и то же время - или просто напишите список и спросите.

Однако я подозреваю, что на самом деле это может не иметь отношения к реальной проблеме вообще, учитывая, что вы видите это даже с самого начала.

Здесь есть три очевидные вещи:

Ошибка в завитке или способ использования.
Что-то не так с вашей настройкой сети (например, ваш интернет-провайдер отключает вас для создания слишком большого количества исходящих подключений или слишком большого количества байтов за 30 минут).
Что-то, что вы делаете, заставляет серверы думать, что вы - атакующий спамер/DoS/все, и они блокируют вас.

Первый на самом деле кажется наименее вероятным. Если вы хотите это исключить, просто запишите все сделанные вами запросы, а затем напишите тривиальный script, который использует некоторую другую библиотеку для воспроизведения одинаковых запросов, и посмотрите, получилось ли у вас одинаковое поведение. Если это так, проблема, очевидно, не может быть в реализации того, как вы делаете свои запросы.

Вы можете различать случаи 2 и 3 в зависимости от времени. Если все службы тайм-аут сразу, особенно если они все делают это, даже когда вы начинаете ударять их в разное время (например, вы начинаете ударять Google + 15 минут после Facebook, и все же они оба тайм-аут через 30 минут после того, как вы нажмете Facebook), это определенно случай 2. Если нет, это может быть случай 3.

Если вы исключите все три из них, вы можете начать искать другие вещи, которые могут быть неправильными, но я бы начал здесь.

Или, если вы расскажете нам больше о том, что делает ваше приложение (например, вы пытаетесь ударить по серверам снова и снова, как только сможете, пытаетесь ли вы подключиться от имени множества пользователей? вы используете ключ разработчика или ключ приложения для конечного пользователя? и т.д.), возможно, кто-то еще с большим опытом работы с этими службами.

Ответ 2

Я не согласен с этим. Я получаю то же сообщение при попытке вызвать веб-сайт через внешний VIP-адрес BIGIP LTM.

Например:

Я вызываю веб-сайт http://11five.10.10.10/index.html (в этом случае IP-адрес является случайным). BIG F5 должен балансировать нагрузку на два внутренних веб-сервера (17two.20.0.10 и 17two.20.0.11) через пул, связанный с виртуальным сервером.

В этом случае запрос, поступающий от внешнего источника (Внутренний клиент) к VIP-адресу в TCP 80, должен объединиться между двумя веб-серверами. Я нахожу, что все серверы получают начальный пакет SYN и никогда не возвращаются к SYN-ACK.

Если я сижу на терминале в локальной подсети, где живут настоящие серверы, я могу "wget" веб-страницу index.html - получен от 17two.20.0.11 до http://17two.20.0.10}/index.html.

Исходя из внешнего, я получаю * дополнительный материал, не отличный transfer.c: 1037 0 0.

Вы правы в том, что это встроенный механизм отладки для CURL в старых версиях библиотеки libcurl, но я не согласен с приведенным ниже инструкцией;

A bug in curl, or the way you're using it.
Something wrong with your network setup (e.g., your ISP cuts you off for making too many outgoing connections or using too many bytes in 30 minutes).
Something you're doing is making the servers think you're a spammer/DoS attacker/whatever and they're blocking you.

Что вызвало это из-за проблемы с сетью в среде, IE.. веб-серверы не могут вернуть трафик обратно исходному источнику и, следовательно, отображает эту ошибку или два, что-то не так с заголовком запроса и ответ обратно с веб-сервера.

В этом случае я хочу сказать, что исходная проблема более вероятна, поскольку, когда я выполнял завиток, используя разные URis в исходном запросе с тестового узла в локальной подсети, я мог получить наилучшую веб-страницу index.html, Это означает, что сервер прослушивает и принимает соединения с использованием полного доменного имени и короткого имени сервера.

Я считаю, что эта ошибка позволяет предположить, что завиток получил ответ, на который он не уверен, и, следовательно, создает вышеупомянутую ошибку. Без разработки curl или чтения исходного кода я больше не могу комментировать.

Любой дополнительный ответ, который задает эту логику, будет приветствоваться - все для изучения новых вещей.

Andy

Ответ 3

подтверждающие

Ошибка в curl, или способ, которым вы его используете.

Информация о Systen: Linux alt 3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 + deb7u1 x86_64 GNU/Linux

Я обновил библиотеку curl и непрерывные сообщения (которые были обнаружены при тестировании apt rest api)

дополнительный материал не очень хороший transfer.c: 1037: 0 0

исчезли

мои недавно обновленные данные curl -version

$curl -V

curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.3 librtmp/2.3 Протоколы: файл dict ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Особенности: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP