CURLE_RECV_ERROR when the SSL server closes the connection immediately after data about curl

[bagder]

You seem to imply that you curl build uses mbedTLS? If so, what version?

I suspect we have changed the logic since the version you're using. It would make sense to verify if 8.6.0 behaves differently.

[chriszhao001]

Yes, I use mbedTLS, ver is 2.16.10. I have tried 8.6.0 and the problem still exists.

[bagder]

Please help us provide a way to reproduce this, or provide much more details that helps us understand in detail what's going on.

[jay]

Possibly the server has not given a termination point. For example the server has not given a content length, ended chunked encoding or a close notify.

[chriszhao001]

The server has given the end flag through chunked encoding, but Curl_read returned an error in the receive loop of readwrite_data, causing the processing error to be returned. Because the environment where the problem occurred on my side is an internal server, it is difficult to provide a reproducible environment. However, I think if the https response returned by the server is chunded encoded and the connection is closed immediately, this problem should appear from the code . Thanks.

[bagder]

The server has given the end flag through chunked encoding

What do you mean?

Are you saying that the server delivered a complete and fine chunked-encoding stream before it closed the connection? It's not exactly an unusual case, and yet curl normally has no problem with that for millions of other users so obviously something is (perhaps subtly) different in your case...

[bagder]

Can you provide a --trace-ascii dump.txt output perhaps?

[chriszhao001]

curl normally has no problem with that for millions of other users

Yes, you are right. Just because this is not a rare phenomenon and curl is widely used, this problem should not occur. The problem I have here is that I used curl7.79.1 and it ran normally. , but when I upgraded to curl7.87.0, I found that there was a problem connecting to the server. Later, I upgraded to curl8.6.0 and found that the problem still existed. I also tried some methods such as adjusting the configuration, but none of them worked. I look deeply into the code and found the difference between 7.87.0 and 7.79.1 when receiving. At the same time, I found that this difference would cause the connection to the server to be fault. So I raised a question. In fact, this is more like a request for help. I want to know what happened (no matter how you look at it, curl should not have problems handling this situation)
The following are two versions of the log I captured after opening curl's DEBUGBUILD macro for easy reference:

7.79.1(success)

* SSL connected
* Didn't find Session ID in cache for host HTTPS://xxxxxxxxx:443
* Added Session ID to cache for HTTPS://xxxxxxxxx:443 [server]
* STATE: PROTOCONNECTING => DO handle 0x622000000100; line 2063 (connection #0)
> POST /sdk HTTP/1.1
Host: xxxxxxxxx
Accept: */*
Content-Length: 46
Content-Type: application/x-www-form-urlencoded

* STATE: DO => DID handle 0x622000000100; line 2129 (connection #0)
* STATE: DID => PERFORMING handle 0x622000000100; line 2259 (connection #0)
curl mbed_recv mbedtls_ssl_read ret 3716
curl Curl_read ret 3716 result 56
curl readwrite_data ret 0 len 3716
* Mark bundle as not supporting multiuse
* HTTP 1.1 or later with persistent connection
< HTTP/1.1 200 OK
< Server: nginx/1.14.0
< Date: Fri, 01 Mar 2024 08:21:57 GMT
< Content-Type: application/json; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: close
< Referrer-Policy: origin
<
* curl readwrite_data OK
* STATE: PERFORMING => DONE handle 0x622000000100; line 2476 (connection #0)
* multi_done: status: 0 prem: 0 done: 0
* The cache now contains 0 members
* Closing connection 0
mbedtls mbedtls_ssl_read
mbedtls mbedtls_ssl_read
* Expire cleared (transfer 0x622000000100)
* curl multi_runsingle 7
* curl multi_runsingle 9 result 0 mstate 15
curl curl_multi_perform multi_runsingle ret 0

7.87.0(failure)

* SSL connected
* [CONN-0] Didn't find Session ID in cache for host HTTPS://xxxxxxxxx:443
* [CONN-0] Added Session ID to cache for HTTPS://xxxxxxxxx:443 [server]
* [CONN-0-0] connect(block=0)-> 0, done=1
* STATE: CONNECTING => PROTOCONNECT handle 0x622000000100; line 2075 (connection #0)
* [CONN-0-0] connect(block=0)-> 0, done=1
* STATE: PROTOCONNECT => DO handle 0x622000000100; line 2105 (connection #0)
> POST /sdk HTTP/1.1
Host: xxxxxxxxx
Accept: */*
Content-Length: 46
Content-Type: application/x-www-form-urlencoded

* STATE: DO => DID handle 0x622000000100; line 2201 (connection #0)
* STATE: DID => PERFORMING handle 0x622000000100; line 2320 (connection #0)
* Curl_readwrite(handle=0x622000000100) -> 0
mbedtls mbedtls_ssl_read
curl mbed_recv ret 3716
curl ssl_cf_recv ret 3716
* Curl_conn_recv(handle=0x622000000100, index=0)-> 3716, err=0
* Mark bundle as not supporting multiuse
* HTTP 1.1 or later with persistent connection
< HTTP/1.1 200 OK
< Server: nginx/1.14.0
< Date: Fri, 01 Mar 2024 07:13:12 GMT
< Content-Type: application/json; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: close
< Referrer-Policy: origin
<
mbedtls mbedtls_ssl_read
curl mbed_recv ret 0
curl ssl_cf_recv ret -1
* Curl_conn_recv(handle=0x622000000100, index=0)-> -1, err=56
curl Curl_read ret -1 result 56
curl readwrite_data ret 56 len 0
* readwrite_data(handle=0x622000000100) -> 56
* curl Curl_readwrite readwrite_data ret 56 done 0
* Curl_readwrite(handle=0x622000000100) -> 56
* multi_done: status: 56 prem: 1 done: 0
* multi_done, not re-using connection=0, forbid=0, close=1, premature=1, stream=0
* The cache now contains 0 members
* Curl_disconnect(conn #0, dead=1)
* Closing connection 0
mbedtls mbedtls_ssl_read
mbedtls mbedtls_ssl_read
* Expire cleared (transfer 0x622000000100)
curl curl_multi_perform multi_runsingle ret 0

[jay]

Can you reproduce with the latest curl? (nevermind, I see you have already tried)

It would be interesting to see a trace using the latest curl.

curl --trace-config all --trace-ids --trace-time --trace outfile ...

[bagder]

A month with no response.