Як усунути неполадки, коли curl отримує * порожню відповідь *

27

Я хочу знати, як діяти з усунення несправностей, чому запит на згортання веб-сервера не працює. Я не шукаю допомоги, яка залежатиме від мого оточення, я просто хочу знати, як збирати інформацію про те, яка саме частина комунікації виходить з ладу, номери портів тощо.

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

Отже, я розумію, що порожня відповідь означає, що curl не отримав жодної відповіді від сервера. Немає проблем, саме це я намагаюся з’ясувати.

Але яку більш конкретну інформацію я можу отримати від CURL тут?

Він зміг успішно "підключитися", так чи це не передбачає деякого двостороннього спілкування? Якщо так, то чому відповідь також не приходить? Зауважте, я перевірив, що моя служба працює і повертає відповіді.

Зауважте, я трохи зелений на цьому рівні роботи в мережі, тому не соромтеся надати деякі загальні орієнтаційні матеріали.

tcp curl

— чад
джерело

1

Я отримував таку ж помилку, але в моєму випадку саме програмне забезпечення VPN перехоплювало та блокувало певний мережевий трафік. Дивіться тут докладніше: stackoverflow.com/a/24189367/703200

— Кріс Бартлі

16

Ви, ймовірно, знадобиться вирішити це з боку сервера, а не з боку клієнта. Я вважаю, що ви плутаєте "порожню відповідь" з "без відповіді". Вони не означають одне і те ж. Ймовірно, ви отримуєте відповідь, яка не містить даних.

Ви можете перевірити це, просто скориставшись telnet замість того, щоб переглядати завитки:

telnet 111.222.159.30 80

Після підключення вставте наступне (узяте з результатів вигину):

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

Ви повинні бачити відповідь саме так, як бачить її завиток.

Однією з можливих причин отримання порожньої відповіді є те, що ви намагаєтесь перейти на веб-сайт, який є віртуальним хостом на основі імен. Якщо це так, залежно від конфігурації сервера (сайт, на який ви намагаєтеся потрапити, буває налаштований за замовчуванням), ви не можете дійти до сайту за IP-адресою без невеликої роботи.

Ви можете перевірити це на стороні клієнта, просто змінивши рядок "Хост" вище; замініть www.example.com на веб-сайт, на який ви намагаєтесь зайти:

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

— йонікс
джерело

Я можу успішно повернути сторінку від іншого клієнта. Думаю, що це стосується певних мереж, на яких може бути клієнт.

— чад

А що стосується порожньої відповіді = немає відповіді, я отримав це від stackoverflow.com/questions/5929971/… , але я готовий розглянути другу думку;)

— чод

1

Вам все одно доведеться усунути неполадки з боку сервера. Якщо сервер не надсилає дані, клієнт не дізнається чому. Він лише знає, що цього не отримав. Щодо порожнього проти ні, я знайшов сервер, який згорнувся на "порожню" відповідь, і я точно отримав відповідь. * Empty reply from serverЗ curl, з'єднання безпосередньо показало всі відповідні заголовки http з тілом, що складається виключно з . Якщо він працює з curl в іншому місці, а не в одній конкретній мережі, я б розглядав відмінності в цій мережі. Можливо, погано поводиться проксі?

— yoonix

7

Curl чудово, але не дає багато відгуків, коли справи йдуть не так. (Як ви можете сказати) wget може дати вам більше інформації, але як згадує yoonix, це місце, де потрібно звернути увагу на сервер (тобто журнали помилок веб-сервера).

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

Ви також можете встановити імена хостів

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

— GeoSword
джерело

2

Спробуйте це -> Замість того, щоб переглядати CURL, спробуйте пінг-сайт, на який ви намагаєтесь зайти з Telnet. Відповідь, яку повертає ваша спроба підключення, буде саме тією, що бачить CURL, коли вона намагається підключитися (але яку вона ненавмисно змушує від вас). Тепер, залежно від того, що ви бачите тут, ви можете зробити один із кількох висновків:

Ви намагаєтеся підключитися до веб-сайту, який базується на імені, віртуального хоста, тобто його не можна отримати через IP-адресу. У імені хоста щось не так - можливо, ви щось помилково ввели. Зауважте, що використання параметрів GET замість POST для параметрів дасть конкретнішу відповідь.

Проблема також може бути прив’язана до заголовка "100". Спробуйте запустити curl_getinfo ($ ch, CURLINFO_HTTP_CODE) і перевірте результат.

— Фелікс
джерело

1

Зауважте (оскільки я бачив, що ви опублікували цю саму відповідь в іншому запитанні CURL): ці питання стосуються cURL, двійкових даних CLI, а не реалізації оболонки PHP, на яку ви посилаєтесь. Іншими словами, getinfoдля CLI CURL немає такого поняття, як прапор чи функція. @see curl.haxx.se

— ken

0

У деяких випадках під WSL Windows. Запуск curl всередині bash призведе до тієї ж помилки, і це тому, що Kasperksy блокує її підключення до HTTP / s.

Про цю помилку тут повідомлялося .

Швидке рішення - відключити захист Касперського на порту, до якого ви намагаєтесь отримати доступ на сервері (tcp 80 для exmaple).

Це робиться, перейшовши до Касперського - Налаштування - Налаштування мережі - встановіть прапорець "Моніторити лише вибрані порти" - Виберіть порти - подвійний клік на порту (80) та виберіть неактивний

— AK_
джерело