33 votes

Comment résoudre le problème de connectivité lorsque curl obtient une réponse *vide* ?

Je veux savoir comment procéder pour résoudre le problème d'une requête curl vers un serveur Web qui ne fonctionne pas. Je ne cherche pas une aide qui dépendrait de mon environnement, je veux juste savoir comment collecter des informations sur la partie exacte de la communication qui échoue, les numéros de port, 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

Donc, je comprends qu'une réponse vide signifie que curl n'a pas reçu de réponse du serveur. Pas de problème, c'est précisément ce que j'essaie de comprendre.

Mais quelles informations plus spécifiques puis-je tirer de cURL ici ?

Il a pu se "connecter" avec succès, ce qui n'implique-t-il pas une communication bidirectionnelle ? Si c'est le cas, pourquoi la réponse ne vient-elle pas aussi ? Remarque : j'ai vérifié que mon service est opérationnel et renvoie des réponses.

Notez que je suis un peu novice à ce niveau de mise en réseau, alors n'hésitez pas à fournir des éléments d'orientation générale.

1 votes

J'obtenais la même erreur, mais dans mon cas, c'était un logiciel VPN qui interceptait et bloquait certains trafics réseau. Voir ici pour en savoir plus : stackoverflow.com/a/24189367/703200

19voto

Vous devrez probablement résoudre ce problème du côté du serveur, et non du côté du client. Je pense que vous confondez une "réponse vide" avec une "absence de réponse". Ils ne signifient pas la même chose. Il est probable que vous obteniez une réponse qui ne contient aucune donnée.

Vous pouvez tester cela en utilisant simplement telnet au lieu de passer par curl :

telnet 111.222.159.30 80

Une fois connecté, collez ce qui suit (extrait de votre sortie curl) :

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: */*

Vous devriez voir la réponse exactement comme curl la voit.

Si vous obtenez une réponse vide, c'est peut-être parce que vous essayez d'accéder à un site Web qui est un hôte virtuel basé sur le nom. Si c'est le cas, en fonction de la configuration du serveur (le site que vous essayez d'atteindre est configuré par défaut), vous ne pouvez pas atteindre le site par adresse IP sans un peu de travail.

Vous pouvez tester cela du côté client en modifiant simplement la ligne "Host" ci-dessus ; remplacez www.example.com par le site que vous essayez d'atteindre :

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: */*

0 votes

Je suis capable de récupérer avec succès la page d'un autre client. C'est spécifique à certains réseaux sur lesquels le client peut se trouver, je pense.

0 votes

Et, pour ce qui est de la réponse vide = pas de réponse, j'ai trouvé ça dans stackoverflow.com/questions/5929971/ mais je suis prêt à considérer une seconde opinion ;)

1 votes

Vous devrez toujours résoudre le problème du côté du serveur. Si le serveur n'envoie pas les données, le client ne saura pas pourquoi. Il sait seulement qu'il ne les a pas reçues. En ce qui concerne la différence entre vide et non, j'ai trouvé un serveur pour lequel curl s'est plaint d'une réponse "vide" et j'ai bien reçu une réponse. * Empty reply from server à partir de curl, en se connectant directement à tous les en-têtes http pertinents, le corps étant constitué uniquement de <!-- b5 --> . Si cela fonctionne avec curl ailleurs et pas sur un réseau spécifique, je regarderais les différences sur ce réseau. Un proxy qui se comporte mal, peut-être ?

7voto

GeoSword Points 1627

La boucle est bonne, mais ne donne pas beaucoup de feedback quand les choses vont mal. (Comme vous pouvez le voir) wget peut vous donner plus d'informations, mais comme le mentionne yoonix, le côté serveur (c'est-à-dire les journaux d'erreurs du serveur) est l'endroit où regarder.

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

Vous pouvez également définir des noms d'hôtes avec

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

1 votes

Y a-t-il une raison pour laquelle vous utilisez des majuscules ? -S dans votre première commande et en minuscules -s dans le second ? Devraient-ils être les mêmes ?

1voto

Felix Points 19

トライ este -> Au lieu de passer par cURL, essayez d'envoyer une requête au site que vous essayez d'atteindre avec Telnet. La réponse que votre tentative de connexion renverra sera exactement ce que cURL verra lorsqu'il essaiera de se connecter (mais qu'il vous cachera de manière inutile). Maintenant, en fonction de ce que vous voyez ici, vous pouvez tirer une ou plusieurs conclusions :

Vous essayez de vous connecter à un site Web qui est un hôte virtuel basé sur le nom, ce qui signifie qu'il ne peut pas être atteint par une adresse IP. Il y a un problème avec le nom d'hôte - vous avez peut-être fait une faute de frappe. Notez que l'utilisation de GET au lieu de POST pour les paramètres vous donnera une réponse plus concrète.

Le problème peut également être lié à l'en-tête 100-continue. Essayez d'exécuter curl_getinfo($ch, CURLINFO_HTTP_CODE), et vérifiez le résultat.

1 votes

Remarque (puisque j'ai vu que vous avez posté cette même réponse dans une autre question sur cURL) : ces questions concernent cURL, le binaire CLI, et non l'implémentation du wrapper PHP auquel vous faites référence. En d'autres termes, il n'existe pas d'application getinfo drapeau ou fonctionnalité pour CLI cURL. @voir curl.haxx.se

0voto

AK_ Points 133

Dans certaines occasions, sous le WSL de Windows. L'exécution de curl dans bash génère la même erreur et c'est parce que Kasperksy bloque la connexion à HTTP/s.

Ce bogue a été signalé aquí .

Une solution rapide est de désactiver la protection de Kaspersky sur le port que vous essayez d'atteindre sur le serveur (tcp 80 par exemple).

Pour ce faire, allez dans Kaspersky - Paramètres - Paramètres réseau - cochez "Surveiller uniquement les ports sélectionnés" - Sélectionnez les ports - double-cliquez sur le port (80) et sélectionnez "inactif".

enter image description here

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X