Cómo solucionar problemas de conectividad cuando curl obtiene una * respuesta vacía *

27

Quiero saber cómo proceder en la solución de problemas por qué una solicitud curl a un servidor web no funciona. No estoy buscando ayuda que dependa de mi entorno, solo quiero saber cómo recopilar información sobre exactamente qué parte de la comunicación está fallando, números de puerto, etc.

chad-integration:~ # curl -v 111.222.159.30
* About to connect() to 111.222.159.30 port 80 (#0)
*   Trying 111.222.159.30... connected
* Connected to 111.222.159.30 (111.222.159.30) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0     OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
> Host: 111.222.159.30
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host 111.222.159.30 left intact
curl: (52) Empty reply from server
* Closing connection #0

Entonces, entiendo que una respuesta vacía significa que curl no recibió ninguna respuesta del servidor. No hay problema, eso es precisamente lo que estoy tratando de resolver.

Pero, ¿qué información más específica puedo obtener de cURL aquí?

Fue capaz de "conectarse" con éxito, entonces, ¿eso no implica alguna comunicación bidireccional? Si es así, ¿por qué la respuesta no viene también? Tenga en cuenta que he verificado que mi servicio está activo y que devuelve respuestas.

Tenga en cuenta que soy un poco verde en este nivel de redes, así que siéntase libre de proporcionar material de orientación general.

tcp curl

— Chad
fuente

1

Recibía el mismo error, pero en mi caso fue el software VPN el que estaba interceptando y bloqueando cierto tráfico de red. Ver aquí para más información: stackoverflow.com/a/24189367/703200

— Chris Bartley

16

Es probable que deba solucionar esto desde el lado del servidor, no desde el lado del cliente. Creo que estás confundiendo una 'respuesta vacía' con 'sin respuesta'. No significan lo mismo. Es probable que reciba una respuesta que no contiene ningún dato.

Puede probar esto simplemente usando telnet en lugar de pasar por curl:

telnet 111.222.159.30 80

Una vez conectado, pegue lo siguiente (tomado de su salida de rizo):

GET / HTTP/1.1
User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0     OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
Host: 111.222.159.30
Accept: */*

Debería ver la respuesta exactamente como curl la ve.

Una posible razón por la que recibe una respuesta vacía es porque está intentando acceder a un sitio web que es un host virtual basado en nombre. Si ese es el caso, dependiendo de la configuración del servidor (el sitio al que intenta acceder está configurado como predeterminado) no puede llegar al sitio por dirección IP sin un poco de trabajo.

Puede probar eso en el lado del cliente simplemente cambiando la línea 'Host' anterior; reemplace www.example.com con el sitio al que intenta acceder:

GET / HTTP/1.1
User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0     OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
Host: www.example.com
Accept: */*

— yoonix
fuente

Puedo recuperar con éxito la página de otro cliente. Creo que es específico de ciertas redes en las que el cliente podría estar.

— chad

Y, en cuanto a la respuesta vacía = sin respuesta, la obtuve de stackoverflow.com/questions/5929971/… , pero estoy dispuesto a considerar una segunda opinión;)

— chad

1

Aún necesitaría solucionarlo desde el lado del servidor. Si el servidor no envía los datos, el cliente no sabrá por qué. Solo sabe que no lo consiguió. En cuanto a vacío vs no, encontré un servidor que curl se quejó de una respuesta 'vacía' y definitivamente recibí una respuesta. * Empty reply from serverdesde el rizo, la conexión mostró directamente todos los encabezados http relevantes con el cuerpo que consiste únicamente en . Si funciona con curl en otro lugar y no en una red específica, vería las diferencias en esa red. ¿Un proxy que se porta mal?

— yoonix

7

Curl está bien, pero no da muchos comentarios cuando las cosas van mal. (Como puede ver) wget puede brindarle más información, pero como yoonix menciona, el lado del servidor (es decir, los registros de errores del servidor web) es el lugar para buscar.

wget -S -O /dev/null http://www.example.com

También puede configurar nombres de host con

wget -s -O /dev/null --header="Host: foo.bar" http://www.example.com

— GeoSword
fuente

2

Intente esto -> En lugar de pasar por cURL, intente hacer ping al sitio al que intenta acceder con Telnet. La respuesta que devuelve su intento de conexión será exactamente lo que cURL ve cuando intenta conectarse (pero que le ofusca inútilmente). Ahora, dependiendo de lo que veas aquí, puedes sacar una de varias conclusiones:

Está intentando conectarse a un sitio web que es un host virtual basado en nombres, lo que significa que no se puede acceder a través de la dirección IP. Algo salió mal con el nombre de host; es posible que hayas escrito mal algo. Tenga en cuenta que usar GET en lugar de POST para los parámetros le dará una respuesta más concreta.

El problema también puede estar relacionado con el encabezado 100-continue. Intente ejecutar curl_getinfo ($ ch, CURLINFO_HTTP_CODE) y verifique el resultado.

— Felix
fuente

1

Nota (desde que vi que publicó esta misma respuesta en una pregunta cURL diferente): estas preguntas son sobre cURL, el binario CLI y no la implementación del contenedor PHP al que hace referencia. En otras palabras, no existe una getinfomarca o característica para CLI cURL. @see curl.haxx.se

— ken

0

En algunas ocasiones bajo WSL de Windows. Ejecutar curl dentro de bash generará el mismo error y eso es porque Kasperksy está bloqueando su conexión a HTTP / s.

Este error ha sido reportado aquí .

Una solución rápida es deshabilitar la protección de Kaspersky en el puerto que está intentando alcanzar en el servidor (tcp 80 para obtener un ejemplo).

Para ello, vaya a Kaspersky - Configuración - Configuración de red - marque "Supervisar solo los puertos seleccionados" - Seleccione puertos - haga doble clic en el puerto (80) y seleccione inactivo

— ALASKA_
fuente