Como solucionar problemas de conectividade quando o curl recebe uma resposta * vazia *

Question

Eu quero saber como proceder na solução de problemas do motivo pelo qual uma solicitação de curl para um servidor da Web não funciona. Eu não estou procurando por ajuda que seria dependente do meu ambiente, eu só quero saber como coletar informações sobre exatamente o que parte da comunicação está falhando, números de porta, 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

Então, eu entendo que uma resposta vazia significa que o curl não recebeu nenhuma resposta do servidor. Não tem problema, é exatamente isso que estou tentando descobrir.

Mas que informações mais específicas posso derivar de cURL aqui?

Foi capaz de "conectar" com sucesso, então isso não envolve alguma comunicação bidirecional? Se sim, então por que a resposta não vem também? Note que verifiquei que meu serviço está ativo e retornando respostas.

Note que eu sou um pouco verde neste nível de rede, então sinta-se à vontade para fornecer algum material de orientação geral.

    

Answer 1

É provável que você precise solucionar isso do lado do servidor, não do lado do cliente. Eu acredito que você está confundindo uma 'resposta vazia' com 'sem resposta'. Eles não significam a mesma coisa. Provavelmente você está recebendo uma resposta que não contém dados.

Você pode testar isso simplesmente usando telnet em vez de passar por curl:

telnet 111.222.159.30 80

Uma vez conectado, cole o seguinte (retirado da saída de sua onda):

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

Você deve ver a resposta exatamente como a onda a vê.

Um possível motivo de você estar recebendo uma resposta vazia é que você está tentando acessar um site que é um host virtual baseado em nome. Se for esse o caso, dependendo da configuração do servidor (o site que você está tentando acertar passa a ser configurado como padrão), você não pode acessar o site por endereço IP sem um pouco de trabalho.

Você pode testar isso no lado do cliente simplesmente alterando a linha 'Host' acima; substitua www.example.com pelo site que você está tentando acessar:

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

    

Answer 2

Curl é bom, mas não dá muito feedback quando as coisas dão errado. (Como você pode dizer) o wget pode lhe dar mais informações, mas como o yoonix menciona, o lado do servidor (ou seja, os logs de erro do servidor web) é o lugar para procurar.

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

Você também pode definir nomes de host com

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

    

Answer 3

Experimente este - & gt ; Em vez de passar pela cURL, tente executar o ping no site que você está tentando acessar com o Telnet. A resposta que a sua tentativa de conexão retorna será exatamente a que a cURL vê quando tenta se conectar (mas que é ofuscante para você). Agora, dependendo do que você vê aqui, você pode tirar uma das várias conclusões:

Você está tentando se conectar a um website que é um host virtual baseado em nome, o que significa que não pode ser acessado por meio do endereço IP. Algo deu errado com o nome do host - você pode ter digitado errado alguma coisa. Observe que usar GET em vez de POST para parâmetros fornecerá uma resposta mais concreta.

O problema também pode estar vinculado ao cabeçalho 100-continue. Tente executar o curl_getinfo ($ ch, CURLINFO_HTTP_CODE) e verifique o resultado.

    

Answer 4

Em algumas ocasiões, no WSL do Windows. Executar curl dentro do bash irá gerar o mesmo erro e isso porque o Kasperksy está impedindo que ele se conecte ao HTTP / s.

Este bug foi reportado aqui .

Uma solução rápida é desabilitar a proteção do Kaspersky na porta que você está tentando acessar no servidor (tcp 80 por exemplo).

Isso é feito indo para o Kaspersky - Configurações - Configurações de Rede - marque "Monitorar apenas as portas selecionadas" - Selecione portas - clique duas vezes na porta (80) e selecione inativo