Jak rozwiązywać problemy z łącznością, gdy curl otrzymuje * pustą odpowiedź *

27

Chcę wiedzieć, jak postępować w rozwiązywaniu problemów, dlaczego żądanie zawinięcia do serwera internetowego nie działa. Nie szukam pomocy, która byłaby zależna od mojego środowiska, chcę tylko wiedzieć, jak zbierać informacje o tym, która część komunikacji nie działa, numery portów itp.

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

Rozumiem więc, że pusta odpowiedź oznacza, że curl nie otrzymał żadnej odpowiedzi z serwera. Nie ma problemu, właśnie to próbuję rozgryźć.

Ale jakie bardziej szczegółowe informacje mogę tu uzyskać z cURL?

Udało mu się „połączyć”, więc czy to nie wymaga komunikacji dwukierunkowej? Jeśli tak, to dlaczego odpowiedź również nie przychodzi? Uwaga: sprawdziłem, czy moja usługa działa i zwraca odpowiedzi.

Uwaga, jestem trochę zielony na tym poziomie sieci, więc nie krępuj się podać ogólne informacje na temat orientacji.

tcp curl

— Czad
źródło

1

Otrzymywałem ten sam błąd, ale w moim przypadku to oprogramowanie VPN przechwytywało i blokowało pewien ruch sieciowy. Zobacz tutaj więcej: stackoverflow.com/a/24189367/703200

— Chris Bartley

16

Prawdopodobnie będziesz musiał rozwiązać ten problem po stronie serwera, a nie po stronie klienta. Uważam, że mylisz „pustą odpowiedź” z „brak odpowiedzi”. Nie oznaczają tego samego. Prawdopodobnie otrzymujesz odpowiedź, która nie zawiera żadnych danych.

Możesz to przetestować, używając telnetu zamiast przewijania:

telnet 111.222.159.30 80

Po podłączeniu wklej następujące elementy (pobrane z wyjścia 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: */*

Powinieneś zobaczyć odpowiedź dokładnie tak, jak widzi ją curl.

Jednym z możliwych powodów otrzymania pustej odpowiedzi jest próba przejścia na stronę internetową, która jest hostem wirtualnym opartym na nazwie. W takim przypadku, w zależności od konfiguracji serwera (strona, którą próbujesz odwiedzić, jest skonfigurowana jako domyślna), nie można uzyskać dostępu do witryny przez adres IP bez odrobiny pracy.

Możesz to sprawdzić po stronie klienta, po prostu zmieniając powyższą linię „Host”; zastąp www.example.com witryną, do której próbujesz dotrzeć:

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
źródło

Jestem w stanie pomyślnie odzyskać stronę od innego klienta. Myślę, że jest to specyficzne dla niektórych sieci, w których klient może być włączony.

— czad

A jeśli chodzi o pustą odpowiedź = brak odpowiedzi, dostałem to od stackoverflow.com/questions/5929971/... , ale jestem gotów rozważyć drugą opinię;)

— czad

1

Nadal będziesz musiał rozwiązać problem po stronie serwera. Jeśli serwer nie wysyła danych, klient nie będzie wiedział dlaczego. Wie tylko, że tego nie dostał. Jeśli chodzi o puste vs nie, znalazłem serwer, który curl narzekał na odpowiedź „pustą” i zdecydowanie otrzymałem odpowiedź. * Empty reply from serverod curl, połączenie bezpośrednio pokazało wszystkie odpowiednie nagłówki http z ciałem składającym się wyłącznie z . Jeśli działa z zawijaniem w innym miejscu, a nie w jednej konkretnej sieci, przyjrzałbym się różnicom w tej sieci. Może źle zachowujący się serwer proxy?

— yoonix

7

Zwijanie jest w porządku, ale nie daje wiele informacji zwrotnych, gdy coś pójdzie nie tak. (Jak możesz powiedzieć) wget może dać ci więcej informacji, ale jak wspomina yoonix, po stronie serwera (tj. Dzienników błędów serwera) jest miejsce, w którym można zajrzeć.

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

Możesz także ustawić nazwy hostów za pomocą

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

— GeoSword
źródło

2

Spróbuj tego -> Zamiast przechodzić przez cURL, spróbuj pingować witrynę, do której próbujesz dotrzeć za pomocą Telnet. Odpowiedź, którą zwróci twoja próba połączenia, będzie dokładnie tym, co cURL widzi, gdy próbuje się połączyć (ale które nieprzydatnie zaciemnia przed tobą). Teraz, w zależności od tego, co tu widzisz, możesz wyciągnąć jeden z kilku wniosków:

Próbujesz połączyć się z witryną, która jest wirtualnym hostem opartym na nazwie, co oznacza, że nie można do niego dotrzeć za pośrednictwem adresu IP. Coś poszło nie tak z nazwą hosta - być może coś źle wpisałeś. Zauważ, że użycie GET zamiast POST dla parametrów daje bardziej konkretną odpowiedź.

Problem może być również powiązany z nagłówkiem 100-Continue. Spróbuj uruchomić curl_getinfo ($ ch, CURLINFO_HTTP_CODE) i sprawdź wynik.

— Felix
źródło

1

Uwaga (ponieważ widziałem, że opublikowałeś tę samą odpowiedź w innym pytaniu cURL): te pytania dotyczą cURL, pliku binarnego CLI, a nie implementacji opakowania PHP, do której się odwołujesz. Innymi słowy, nie ma czegoś takiego jak getinfoflaga lub funkcja dla CLI cURL. @see curl.haxx.se

— Ken

0

W niektórych przypadkach w ramach WSL systemu Windows. Uruchomienie curl wewnątrz bash wygeneruje ten sam błąd, a to dlatego, że Kasperksy blokuje mu połączenie z HTTP / s.

Ten błąd został zgłoszony tutaj .

Szybkim rozwiązaniem jest wyłączenie ochrony Kaspersky na porcie, do którego próbujesz dotrzeć na serwerze (tcp 80 dla exmaple).

W tym celu przejdź do Kaspersky - Ustawienia - Ustawienia sieciowe - zaznacz „Monitoruj tylko wybrane porty” - Wybierz porty - kliknij dwukrotnie port (80) i wybierz nieaktywny

— AK_
źródło