Je veux savoir comment procéder pour dépanner pourquoi une demande de bouclage vers un serveur Web ne fonctionne pas. Je ne cherche pas d'aide qui dépendrait de mon environnement, je veux juste savoir comment collecter des informations sur la partie 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 reçu aucune 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 réussi à "se connecter", donc cela n'implique-t-il pas une communication bidirectionnelle? Si oui, alors pourquoi la réponse ne vient-elle pas également? Remarque, j'ai vérifié que mon service est opérationnel et je retourne des réponses.
Remarque, je suis un peu vert à ce niveau de réseautage, alors n'hésitez pas à fournir du matériel d'orientation général.
Réponses:
Vous devrez probablement résoudre ce problème côté serveur, pas côté client. Je crois que vous confondez une «réponse vide» avec «aucune réponse». Ils ne signifient pas la même chose. Vous obtenez probablement une réponse qui ne contient aucune donnée.
Vous pouvez tester cela en utilisant simplement telnet au lieu de passer par curl:
Une fois connecté, collez ce qui suit (tiré de votre sortie curl):
Vous devriez voir la réponse exactement comme curl la voit.
Une raison possible pour laquelle vous obtenez une réponse vide est 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 de visiter se trouve être configuré par défaut), vous ne pouvez pas accéder au site par adresse IP sans un peu de travail.
Vous pouvez tester cela du côté client en changeant simplement la ligne «Host» ci-dessus; remplacez www.example.com par le site que vous essayez d'atteindre:
la source
* Empty reply from serverde curl, la connexion directe a montré tous les en-têtes http pertinents avec le corps constitué uniquement de<!-- b5 -->. Si cela fonctionne avec curl ailleurs et non sur un réseau spécifique, j'examinerais les différences sur ce réseau. Un proxy mal se comporter peut-être?Curl est bien, mais ne donne pas beaucoup de commentaires lorsque les choses tournent 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 Web) est l'endroit où chercher.
Vous pouvez également définir des noms d'hôtes avec
la source
Essayez ceci -> Au lieu de passer par cURL, essayez d'envoyer une requête ping au site que vous essayez d'atteindre avec Telnet. La réponse renvoyée par votre tentative de connexion sera exactement ce que cURL verra lorsqu'il essaiera de se connecter (mais qu'il vous masquera sans aide). Maintenant, en fonction de ce que vous voyez ici, vous pouvez tirer l'une des conclusions suivantes:
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 via l'adresse IP. Quelque chose ne va pas avec le nom d'hôte - vous avez peut-être mal saisi quelque chose. 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.
la source
getinfoindicateur ou de fonctionnalité pour CLI cURL. @see curl.haxx.seDans certains cas, sous WSL de Windows. L'exécution de curl dans bash générera la même erreur et c'est parce que Kasperksy l'empêche de se connecter à HTTP / s.
Ce bug a été signalé ici .
Une solution rapide consiste à désactiver la protection de Kaspersky sur le port que vous essayez d'atteindre sur le serveur (tcp 80 pour exmaple).
Pour cela, accédez à 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
la source