31

I want to know how to proceed in troubleshooting why a curl request to a webserver doesn't work. I'm not looking for help that would be dependent upon my environment, I just want to know how to collect information about exactly what part of the communication is failing, port numbers, 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

So, I understand that an empty response means that curl didn't get any response from the server. No problem, that's precisely what I'm trying to figure out.

But what more specific info can I derive from cURL here?

It was able to successfully "connect", so doesn't that involve some bidirectional communication? If so, then why does the response not come also? Note, I've verified my service is up and returning responses.

Note, I'm a bit green at this level of networking, so feel free to provide some general orientation material.

chad
  • 429
  • 1
  • 4
  • 8
  • 1
    I was getting the same error, but in my case it was VPN software that was intercepting and blocking certain network traffic. See here for more: http://stackoverflow.com/a/24189367/703200 – Chris Bartley Jun 12 '14 at 16:28

4 Answers4

18

You likely will need to troubleshoot this from the server side, not the client side. I believe you are confusing an 'empty response' with 'no response'. They do not mean the same thing. Likely you are getting a reply that does not contain any data.

You can test this by simply using telnet instead of going through curl:

telnet 111.222.159.30 80

Once connected, paste the following (taken from your curl output):

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

You should see the response exactly as curl sees it.

One possible reason you are getting an empty reply is that you're trying to hit a website that is a name-based virtual host. If that's the case, depending on server configuration (the site you're trying to hit happens to be configured as the default) you cannot reach the site by IP address without a little bit of work.

You can test that on the client side by simply changing the 'Host' line above; replace www.example.com with the site you're trying to reach:

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: */*
  • I'm able to successfully get the page back from another client. It's specific to certain networks that the client might be on, I think. – chad Oct 17 '13 at 20:08
  • And, as for the empty response = no response, I got that from http://stackoverflow.com/questions/5929971/c-curl-empty-reply-from-server-every-time , but I'm willing to consider a second opinion ;) – chad Oct 17 '13 at 20:08
  • 1
    You'd still need to troubleshoot it from the server side. If the server is not sending the data, the client won't know why. It only knows it didn't get it. As for empty vs no, I found a server that curl complained about an 'empty' response and I definitely received a response. `* Empty reply from server` from curl, connecting directly showed all the relevant http headers with the body consisting purely of ``. If it works with curl elsewhere and not on one specific network, I'd look at the differences on that network. A poorly behaving proxy perhaps? –  Oct 17 '13 at 20:11
7

Curl is fine, but doesnt give much feedback when things go wrong. (As you can tell) wget may give you more information, but as yoonix mentions, Server side (ie webserver error logs) is the place to look. 

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

You can set hostnames as well with 

wget -s -O /dev/null --header="Host: foo.bar" http://www.example.com
GeoSword
  • 1,647
  • 12
  • 16
  • Is there a reason you use uppercase `-S` in your first command and lowercase `-s` in the second? Should they be the same? – falsePockets May 16 '20 at 00:35
1

Try this -> Instead of going through cURL, try pinging the site you’re trying to reach with Telnet. The response that your connection attempt returns will be exactly what cURL sees when it tries to connect (but which it unhelpfully obfuscates from you). Now, depending on what what you see here, you might draw one of several conclusions:

You’re attempting to connect to a website that’s a name-based virtual host, meaning it cannot be reached via IP address. Something’s gone wrong with the hostname – you may have mistyped something. Note that using GET instead of POST for parameters will give you a more concrete answer.

The issue may also be tied to the 100-continue header. Try running curl_getinfo($ch, CURLINFO_HTTP_CODE), and check the result.

Felix
  • 19
  • 1
  • 1
    Note (since I saw you posted this same answer in a different cURL question): these questions are about cURL, the CLI binary, and not the PHP wrapper implementation you're referencing. In other words, there's no such thing as a `getinfo` flag or feature for CLI cURL. @see https://curl.haxx.se/ – ken Oct 05 '17 at 17:39
0

In some occasions under Windows's WSL. Running curl inside bash will generate the same error and that's because Kasperksy is blocking it from connecting to HTTP/s.

This bug has been reported here.

A quick solution is to disable Kaspersky's protection on the port you're trying to reach on the server (tcp 80 for exmaple).

This is done by going to Kaspersky - Settings - Network Settings - check "Monitor selected ports only" - Select ports - double clikc on the port (80) and select inactive

enter image description here

AK_
  • 133
  • 7