cURL - ... sometimes fails with cryptic messages

mail

curl: (35) Recv failure: Connection reset by peer

Situation

For the context : I stumbled on this while trying to nslookup through an HTTP proxy.
curl -H "Content-Type: application/dns-json" "https://dns.google.com/resolve?name=www.google.com&type=A" -v
* Host proxy.myCompany.tld:8080 was resolved.
* IPv6: (none)
* IPv4: 192.168.164.2
*   Trying 192.168.164.2:8080...
* CONNECT tunnel: HTTP/1.1 negotiated
* allocate connect buffer
* Proxy auth using Basic with user 'bob'
* Establish HTTP proxy tunnel to dns.google.com:443
> CONNECT dns.google.com:443 HTTP/1.1
> Host: dns.google.com:443
> Proxy-Authorization: Basic eHMyZTE4NzI6b29ndUJpQmlebGV4bzM=
> User-Agent: curl/8.14.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* CONNECT phase completed
* CONNECT tunnel established, response 200
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* TLS connect error: error:00000000:lib(0)::reason(0)
* OpenSSL SSL_connect: Connection reset by peer in connection to dns.google.com:443
* closing connection #0
curl: (35) Recv failure: Connection reset by peer

Solution

This may not be the only fix/workaround.
Restrain to a lower TLS protocol version :
curl --tls-max 1.2
mail

curl -I : why do I see 2 blocks of HTTP headers ?

Situation

While running tests on my company's internally hosted Jira instance, I send HTTP requests with cURL :

Details

I was not aware of the details below while facing this question and scratching my head, this may let the cat out of the bag .
This may look obvious after keeping only the relevant lines and with the highlights above, but it was not that clear in the beginning, especially when grepping the HTTP status code .
Anyway, this is not :

Solution

This is simply because the HTTP request —originating from my workstation on the corporate network— had to go through a web proxy to reach the Apache server. And cURL is kind enough to report about this extra hop.
mail

curl: (35) error:0A00010B:SSL routines::wrong version number

Situation

curl -x https://10.27.26.37:3128 -o /etc/yum.repos.d/docker-ce.repo https://download.docker.com/linux/centos/docker-ce.repo
curl: (35) error:0A00010B:SSL routines::wrong version number

Details

As already seen here and here, the https:// in the proxy value (-x parameter) is wrong and should be http://.
The proxy itself is accessed by HTTP (not HTTPS) even though the target URL is HTTPS. The proxy will nevertheless properly handle HTTPS connection and keep the end-to-end encryption. See HTTP CONNECT method for details.

Solution

Replay the same command with http in the proxy value :
curl -x http://
mail

TLSv1.2 (IN), TLS alert, close notify (256):

close_notify
This message notifies the recipient that the sender will not send any more messages on this connection. Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice.
mail

Expire in 0 ms for 1 (transfer 0x559d3dcc1bb0)

This is actually a debug message forgotten in the code and removed in february 2019.
mail

curl: (52) Empty reply from server

Many reasons can cause this reply.

Reason 1 : you're doing it wrong :

curl http://12.34.56.78:443
curl: (52) Empty reply from server
curl https://12.34.56.78
curl: (35) Unknown SSL protocol error in connection to 12.34.56.78:443
When you want to use HTTPS (i.e. SSL / TLS over HTTP), you'll have to specify it in the scheme part of the URL, not with a trailing :443 (source) :
  • DO : curl https://example.com
  • DON'T : curl http://example.com:443
This is why commands using :443 fail : they're sending HTTP requests to the port 443 of the remote host, whereas this one is actually expecting HTTPS requests.

Let's have a look at this in more details :

One of the causes of this curl: (52) Empty reply from server error message would then be trying to use HTTP on a host only serving HTTPS. Let's check it :
curl http://12.34.56.78
curl: (7) couldn't connect to host
nc -vzn 12.34.56.78 80 443
(UNKNOWN) [12.34.56.78] 80 (http) : Connection timed out
(UNKNOWN) [12.34.56.78] 443 (https) open
Confirmed !

Reason 2 : nobody's listening :

Once you've confirmed you're using cURL the right way, the reason why nobody replies is probably because nobody is listening (or you're not talking to the right guy ). To debug this, make sure :
  1. you get a similar empty response, no data sent from server, or something like that with an other tool such as wget or the Web Developer Firefox extension
  2. DNS resolution works as expected (and you're actually sending requests to the right server )
  3. you're contacting the right virtualhost (if any). Have a look at the access.log / error.log
  4. some process is actually listening on the specified IP+port
  5. the network configuration (route, firewall, forward + reverse proxy, NAT, ...) actually leads requests to this listening socket.
    Don't hesitate to sketch the desired vs observed setup : the bug is on one of those arrows
mail

curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

Details

This is often caused by improperly setting the HTTP / HTTPS proxy value.
incorrect
http_proxy=http://proxyHost:proxyPort
https_proxy=https://proxyHost:proxyPort
correct
http_proxy=http://proxyHost:proxyPort
https_proxy=http://proxyHost:proxyPort

Solution

mail

What does additional stuff not fine transfer.c:1037: 0 0 mean ?

Situation

A curl query returns a 141 exit code, and the message :
* additional stuff not fine transfer.c:1037: 0 0
* SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
* Closing connection #0
What does that mean ?
Looks like this errno 104 is an SSL error, and is unrelated to cURL.

Details

From Daniel Stenberg, the author of cURL :

About the 141 exit code (source) :

It usually means curl crashed (segfaulted) or similar.

About additional stuff not fine transfer.c:1037: 0 0 (source) :

> Under what circumstances will cURL print the following message:
> * additional stuff not fine transfer.c:1037: 0 0

That's a debug output I put there once to aid me debugging a transfer case I
had problems with and I then left it there. It is only present in debug builds
and basically if you need to ask about it, the message is not for you...

Solution

mail

curl: (56) Recv failure: Connection reset by peer 

Failure with receiving network data

https://stackoverflow.com/questions/10285700/curl-error-recv-failure-connection-reset-by-peer-php-curl#10349895
mail

curl: (7) Unsupported proxy scheme for 'https://login:password@proxy.company.tld:port'

cURL doesn't support HTTPS proxy so you'll get this message to make you aware of that so that you don't think you're actually using a HTTPS proxy. You can workaround this by resetting the https_proxy environment variable, then retrying your cURL request :

https_proxy=http://login:password@proxy.company.tld:port; curl