it-swarm.com.de

Fehlerbehebung bei Konnektivität, wenn Curl eine * leere Antwort * erhält

Ich möchte wissen, wie bei der Fehlerbehebung vorgegangen wird, warum eine Curl-Anforderung an einen Webserver nicht funktioniert. Ich suche keine Hilfe, die von meiner Umgebung abhängt. Ich möchte nur wissen, wie ich Informationen darüber sammeln kann, welcher Teil der Kommunikation fehlschlägt, welche Portnummern usw.

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

Ich verstehe also, dass eine leere Antwort bedeutet, dass Curl keine Antwort vom Server erhalten hat. Kein Problem, genau das versuche ich herauszufinden.

Aber welche genaueren Informationen kann ich hier von cURL ableiten?

Es konnte erfolgreich "verbunden" werden, beinhaltet dies also keine bidirektionale Kommunikation? Wenn ja, warum kommt dann nicht auch die Antwort? Hinweis: Ich habe überprüft, ob mein Dienst aktiv ist, und habe Antworten zurückgegeben.

Beachten Sie, dass ich auf dieser Ebene der Vernetzung ein bisschen grün bin. Sie können also gerne allgemeines Orientierungsmaterial bereitstellen.

28
chad

Sie müssen dies wahrscheinlich auf der Serverseite und nicht auf der Clientseite beheben. Ich glaube, Sie verwechseln eine "leere Antwort" mit "keine Antwort". Sie bedeuten nicht dasselbe. Wahrscheinlich erhalten Sie eine Antwort, die keine Daten enthält.

Sie können dies testen, indem Sie einfach Telnet verwenden, anstatt sich zu kräuseln:

telnet 111.222.159.30 80

Fügen Sie nach dem Verbinden Folgendes ein (entnommen aus Ihrer Curl-Ausgabe):

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

Sie sollten die Antwort genau so sehen, wie Curl sie sieht.

Ein möglicher Grund, warum Sie eine leere Antwort erhalten, ist, dass Sie versuchen, eine Website aufzurufen, die ein namenbasierter virtueller Host ist. Wenn dies der Fall ist, können Sie abhängig von der Serverkonfiguration (die Site, auf die Sie zugreifen möchten, standardmäßig konfiguriert ist) die Site nicht ohne ein wenig Arbeit über die IP-Adresse erreichen.

Sie können dies auf der Clientseite testen, indem Sie einfach die obige Zeile 'Host' ändern. Ersetzen Sie www.example.com durch die Website, die Sie erreichen möchten:

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

Curl ist in Ordnung, gibt aber nicht viel Feedback, wenn etwas schief geht. (Wie Sie sehen können) wget gibt Ihnen möglicherweise weitere Informationen, aber wie yoonix erwähnt, ist die Serverseite (dh Webserver-Fehlerprotokolle) der richtige Ort, um nachzuschauen.

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

Sie können auch Hostnamen mit festlegen

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

Versuchen Sie this -> Anstatt cURL zu durchlaufen, versuchen Sie, die Site, die Sie mit Telnet erreichen möchten, zu pingen. Die Antwort, die Ihr Verbindungsversuch zurückgibt, ist genau die, die cURL sieht, wenn es versucht, eine Verbindung herzustellen (die es jedoch nicht hilfreich von Ihnen verschleiert). Je nachdem, was Sie hier sehen, können Sie nun eine von mehreren Schlussfolgerungen ziehen:

Sie versuchen, eine Verbindung zu einer Website herzustellen, bei der es sich um einen namensbasierten virtuellen Host handelt. Dies bedeutet, dass diese nicht über die IP-Adresse erreichbar ist. Mit dem Hostnamen ist ein Fehler aufgetreten. Möglicherweise haben Sie etwas falsch eingegeben. Beachten Sie, dass Sie mit GET anstelle von POST für Parameter eine konkretere Antwort erhalten.

Das Problem kann auch mit dem 100-Continue-Header verbunden sein. Versuchen Sie, curl_getinfo ($ ch, CURLINFO_HTTP_CODE) auszuführen, und überprüfen Sie das Ergebnis.

2
Felix

In einigen Fällen unter Windows WSL. Wenn Sie curl in bash ausführen, wird derselbe Fehler generiert. Dies liegt daran, dass Kasperksy die Verbindung zu HTTP/s blockiert.

Dieser Fehler wurde gemeldet hier .

Eine schnelle Lösung besteht darin, den Schutz von Kaspersky für den Port zu deaktivieren, den Sie auf dem Server erreichen möchten (z. B. TCP 80).

Gehen Sie dazu zu Kaspersky - Einstellungen - Netzwerkeinstellungen - aktivieren Sie "Nur ausgewählte Ports überwachen" - Ports auswählen - Doppelklick auf den Port (80) und wählen Sie Inaktiv

(enter image description here

0
AK_