Some tests fail with libcurl 8.11.1

[Jerry-Terrasse]

Description

When running tests after building cpr, I get:

81% tests passed, 5 tests failed out of 27

Total Test time (real) =  23.41 sec

The following tests FAILED:
	  1 - cpr_get_tests (Failed)
	  2 - cpr_post_tests (Failed)
	  6 - cpr_head_tests (Failed)
	 10 - cpr_raw_body_tests (Failed)
	 13 - cpr_error_tests (Failed)

LastTest.log

Example/How to Reproduce

git clone [email protected]:libcpr/cpr.git
cd cpr && mkdir build && cd build
cmake .. -DCPR_USE_SYSTEM_CURL=ON -DBUILD_SHARED_LIBS=OFF -DCPR_USE_SYSTEM_GTEST=ON -DCPR_BUILD_TESTS=ON -Wno-dev
cmake --build . --parallel
ctest

Possible Fix

I've had a look into test/get_tests.cpp, the test failed at line:

EXPECT_EQ(ErrorCode::COULDNT_RESOLVE_HOST, response.error.code);

In LastTest.log:

Expected equality of these values:
  ErrorCode::COULDNT_RESOLVE_HOST
    Which is: 4-byte object <06-00 00-00>
  response.error.code
    Which is: 4-byte object <07-00 00-00>

Which means libcurl on my machine returns error code 7 instead of 6:

$ curl --version
curl 8.11.1 (x86_64-pc-linux-gnu) libcurl/8.11.1 OpenSSL/3.4.0 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 libpsl/0.21.5 libssh2/1.11.0 nghttp2/1.64.0 nghttp3/1.6.0
Release-Date: 2024-12-11
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
$ curl "http://bad_host/"
curl: (7) Failed to connect to bad_host port 80 after 380 ms: Could not connect to server
$ echo $?
7

Therefore, maybe it's caused by a change in the upstream libcurl.

Where did you get it from?

GitHub (branch e.g. master)

Additional Context/Your Environment

• OS: Manjaro Linux 24.2.1
• cpr version: 1.11.1
• curl version: 8.11.1

[Jerry-Terrasse]

UPDATE:

I found out that it's because my router resolved all bad_host to 127.0.0.2 for some unknown purpose. That's why curl return CURLE_COULDNT_CONNECT (7) instead of CURLE_COULDNT_RESOLVE_HOST (6).

$ curl bad_host -v
* Host bad_host:80 was resolved.
* IPv6: (none)
* IPv4: 127.0.0.2
*   Trying 127.0.0.2:80...
* connect to 127.0.0.2 port 80 from 127.0.0.1 port 49058 failed: Connection refused
* Failed to connect to bad_host port 80 after 144 ms: Could not connect to server
* closing connection #0
curl: (7) Failed to connect to bad_host port 80 after 144 ms: Could not connect to server

I didn't know if it's a common issue. Maybe it's better to consider this situation and let it pass the tests?

Thanks a lot for your great work!

[COM8]

@Jerry-Terrasse thanks for reporting and investigating this!

A "or" between those two error codes would make them more reliable indeed.

I would be open for a PR introduction this "fix" with a comment explaining why.