¿Por qué cURL está devolviendo "cosas adicionales no está bien"?

Question

¿Por qué cURL está devolviendo "cosas adicionales no está bien"?

Estoy escribiendo una aplicación Python que consulta las API de redes sociales a través de cURL. La mayoría de los diferentes servidores que consulta (Google+, Reddit, Twitter, Facebook, otros) tienen Curl quejándose:

Material adicional no transferencia fina.c: 1037: 0 0

Lo inusual es que cuando la aplicación se inicia por primera vez, la respuesta de cada servicio lanzará esta línea una o dos veces. Después de unos minutos, la línea aparecerá varias veces. Obviamente cURL está identificando algo eso no le gusta. Después de aproximadamente media hora, los servidores comienzan a agotar el tiempo y esta línea se repite muchas decenas de veces, por lo que está mostrando un problema real.

¿Cómo puedo diagnosticar esto? Intenté usar Wireshark para capturar los encabezados de solicitud y respuesta para buscar anomalías que pudieran causar que cURL se quejara, pero para toda la complejidad de Wireshark no parece haber una manera de aislar y mostrar solo los encabezados.

Aquí está la parte relevante del código:

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

23

python curl

Author: Peter O., 2012-12-19

Source

3 answers

No estoy de acuerdo con esto: recibo el mismo mensaje cuando intento llamar a un sitio web a través de una dirección VIP externa de BIGIP LTM.

Por ejemplo:

Llamo al sitio web http://11five.10.10.10 / índice.html (la dirección IP es aleatoria en este caso). La GRAN F5 debería equilibrar la carga del tráfico a dos servidores web internos (17dwo.20.0.10 and 17two.20.0.11) a través de un grupo asociado con el servidor virtual.

En este caso, la solicitud procedente de la fuente externa (Interna Cliente) a la dirección VIP en TCP 80 debe round robin entre los dos servidores web. Lo que encuentro es que todos los servidores reciben un paquete SYN inicial y nunca un SYN-ACK de vuelta.

Si me siento en un terminal dentro de la subred local donde residen los servidores reales, puedo "wget" el índice.página web html-fuente de 17two.20.0.11 a http://17two.20.0.10}/index.HTML.

Viniendo de externo, me sale el *material adicional no transferencia fina.c: 1037 0 0 mensaje.

Usted es correcto al decir que es un mecanismo de depuración incorporado para CURL en revisiones anteriores de la biblioteca libcurl, pero no estoy de acuerdo con la siguiente declaración;

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.

Lo que siempre está causando esto se debe a un problema de red dentro del entorno, es decir, a un problema de red... los servidores web no pueden devolver el tráfico a la fuente original y, por lo tanto, muestra este error o dos, hay algo mal con el encabezado de la solicitud y la respuesta del servidor web.

En este caso optaré por decir que el problema original es más probable, ya que cuando realicé un curl usando diferentes URI en la solicitud original de un host de prueba en la subred local, pude recuperar el índice.página web html bien. Esto implica que el servidor está escuchando y aceptando conexiones usando el FQDN y el nombre corto del servidor.

Creo que este error está ahí para sugerir que curl recibió una respuesta que no está seguro y por lo tanto produce el error anterior. Sin desarrollar curl o leer la fuente código, no puedo comentar más.

Cualquier respuesta adicional que cuestione esta lógica sería bienvenida - todo listo para aprender cosas nuevas.

Andy

4

Author: Andrew,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-04-21 09:40:24

Confirmando

Un error en curl, o la forma en que lo estás usando.

Información del sistema: Linux alt 3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 + deb7u1 x86_64 GNU/Linux

He actualizado la biblioteca curl, y los mensajes continuos (que fueron capturados en twitter rest api testing)

material adicional no transferencia fina.c: 1037: 0 0

Han desaparecido

Mis datos de versión de curl newly recién actualizados

Cur curl-V

Curl 7.38.0 (x86_64-pc-linux-gnu) libcurl / 7.38.0 OpenSSL / 1.0.1 e zlib / 1.2.7 libidn / 1.25 libssh2 / 1.4.3 librtmp / 2.3 Protocolos: archivo dict ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Características: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP

0

Author: Arij,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-10-26 10:52:01

score 28 · Accepted Answer

Estoy 99.99% seguro de que esto no está realmente en ninguna cabecera HTTP, sino que está siendo impreso en stderr por libcurl. Posiblemente esto sucede en medio de ti registrando los encabezados, por lo que estabas confundido.

De todos modos, una búsqueda rápida de "additional stuff not fine" curl transfer.c apareció un cambio reciente en la fuente donde la descripción es:

Curl_readwrite: eliminar la salida de depuración

El texto" cosas adicionales no está bien " se agregó para fines de depuración a hace tiempo, pero realmente no está ayudando a nadie y por alguna razón algunos Las distribuciones de Linux proporcionan sus libcurls construidos con información de depuración todavía presente y por lo tanto (demasiados) los usuarios llegan a leer esta información.

Por lo tanto, esto es básicamente inofensivo, y la única razón por la que lo está viendo es que tiene una compilación de libcurl (probablemente de su distribución de linux) que tenía el registro de depuración completo habilitado (a pesar de que el autor de curl piensa que es una mala idea). Así que tienes tres opciones:

ignorarlo.
Actualice a una versión posterior de libcurl.
Reconstruir libcurl sin información de depuración.

Puede mirar la fuente libcurl de transfer.c (como se enlaza anteriormente) para tratar de entender de qué se queja curl, y posiblemente buscar hilos en la lista de correo alrededor del mismo tiempo-o simplemente enviar por correo electrónico la lista y preguntar.

Sin embargo, sospecho que en realidad puede no ser relevante para el problema real en absoluto, dado que está viendo esto incluso desde el principio.

Hay tres cosas obvias que podrían estar yendo mal aquí:

Un error en curl, o la forma en que lo estás usando.
Algo malo con la configuración de su red (por ejemplo, su ISP lo interrumpe por hacer demasiadas conexiones salientes o usar demasiados bytes en 30 minutos).
Algo que estás haciendo es hacer que los servidores piensen que eres un spammer/atacante DoS/lo que sea y te están bloqueando.

El primero en realidad parece el menos probable. Si desea descartarlo, simplemente capture todas las solicitudes que realice y luego escriba un script trivial que use alguna otra biblioteca para reproducir exactamente las mismas solicitudes, y vea si obtiene el mismo comportamiento. Si es así, el problema obviamente no puede estar en la implementación de cómo hacer sus solicitudes.

Es posible que pueda distinguir entre los casos 2 y 3 en función del momento. Si todos los servicios se extinguen a la vez, especialmente si todos lo hacen incluso cuando comienzas golpearlos en diferentes momentos (por ejemplo, usted comienza a golpear a Google+ 15 minutos después de Facebook, y sin embargo ambos tiempo fuera 30 minutos después de que usted golpea Facebook), es definitivamente caso 2. Si no, podría ser el caso 3.

Si descartas los tres, entonces puedes empezar a buscar otras cosas que podrían estar mal, pero yo empezaría aquí.

O, si nos dice más sobre exactamente lo que hace su aplicación (por ejemplo, ¿intenta golpear los servidores una y otra vez lo más rápido posible? intenta conectarse en nombre de una gran cantidad de usuarios diferentes? ¿está utilizando una clave de desarrollo o una clave de aplicación de usuario final? sucesivamente.), podría ser posible que alguien más con más experiencia con esos servicios adivine.