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

27

Quero saber como proceder na solução de problemas por que uma solicitação de ondulação para um servidor da web não funciona. Não estou procurando ajuda que dependa do meu ambiente, só quero saber como coletar informações sobre exatamente qual parte da comunicação está falhando, números de portas 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

Portanto, entendo que uma resposta vazia significa que o curl não obteve 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?

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

Observe que estou um pouco verde nesse nível de rede, portanto, fique à vontade para fornecer algum material de orientação geral.

tcp curl

— Chade
fonte

11

Eu estava recebendo o mesmo erro, mas no meu caso, era um software VPN que interceptava e bloqueava certo tráfego de rede. Veja aqui para mais: stackoverflow.com/a/24189367/703200

— Chris Bartley

16

Você provavelmente precisará solucionar isso no lado do servidor, não no lado do cliente. Acredito que você esteja 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 nenhum dado.

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

telnet 111.222.159.30 80

Depois de conectado, cole o seguinte (retirado da saída de curvatura):

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 vê.

Um possível motivo para você receber 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 acessar está configurado como padrão), não é possível 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: */*

— yoonix
fonte

Consigo recuperar a página de outro cliente. É específico para determinadas redes em que o cliente pode estar, eu acho.

— chad

E, como para a resposta vazio = nenhuma resposta, eu tenho que partir stackoverflow.com/questions/5929971/... , mas estou disposto a considerar uma segunda opinião;)

— chad

11

Você ainda precisará solucionar o problema do lado do servidor. Se o servidor não estiver enviando os dados, o cliente não saberá o porquê. Só sabe que não conseguiu. Quanto ao vazio vs não, encontrei um servidor que curl reclamou de uma resposta 'vazia' e definitivamente recebi uma resposta. * Empty reply from serverde curl, a conexão mostrava diretamente todos os cabeçalhos http relevantes com o corpo constituído apenas por . Se ele funciona com curl em outro lugar e não em uma rede específica, eu observaria as diferenças nessa rede. Um proxy mal comportado, talvez?

— Yoonix 17/10/2013

7

Curl é bom, mas não dá muito feedback quando as coisas dão errado. (Como você pode ver), o wget pode fornecer mais informações, mas como yoonix menciona, o lado do servidor (ou seja, os logs de erros do servidor da 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

— GeoSword
fonte

2

Tente isso -> Em vez de passar pelo cURL, tente executar o ping no site que você está tentando acessar com o Telnet. A resposta que sua tentativa de conexão retornará será exatamente o que o cURL verá quando tentar se conectar (mas que será ofuscado por você). Agora, dependendo do que você vê aqui, você pode tirar uma das várias conclusões:

Você está tentando se conectar a um site que é um host virtual baseado em nome, o que significa que ele não pode ser acessado via endereço IP. Algo deu errado com o nome do host - você pode ter digitado algo errado. 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 de 100 continuações. Tente executar curl_getinfo ($ ch, CURLINFO_HTTP_CODE) e verifique o resultado.

— Felix
fonte

11

Nota (desde que eu vi você postar a mesma resposta em uma pergunta cURL diferente): essas perguntas são sobre cURL, o binário da CLI e não a implementação do wrapper PHP que você está referenciando. Em outras palavras, não existe getinfosinalizador ou recurso para CLI cURL. @see curl.haxx.se

— ken

0

Em algumas ocasiões, sob o WSL do Windows. A execução do curl no bash gerará o mesmo erro e é porque o Kasperksy está impedindo a conexão com o HTTP / s.

Este bug foi relatado aqui .

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

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

— AK_
fonte