Curl vs. reqwest

[ralph-bergmann]

Just out of curiosity, would you use Curl again today, or would you use reqwest instead? Are there any features that can only be implemented with Curl?

[SilenLoc]

Just out of curiosity, would you use Curl again today, or would you use reqwest instead? Are there any features that can only be implemented with Curl?

I am not a maintainer but:

Actual answer

My assumption on one of the features (@jcamiel, pls correct me if I am wrong):

hurl test.hurl --very-verbose

that prints the curl command that would replicate the call that hurl made would not make sense or is inaccurate if Hurl would not use Curl.

My experience about the topic of Curl

It was easy to argue about why we should use it in the Company because it uses curl under the hood.

Many of our Devs were anxious about how it works under the hood and thought in the beginning it would make magic things when doing the request. People trust Curl to be secure, well maintained and fast.

Of course reqwest is also all of those things, but if you are not living in Rust world, Curl sound a lot more familiar and a safe bet.
Then telling them that Hurl is an amazing test driver around Curl it makes them say yes to it.

When working and trying out things with Hurl, it felt good because you knew when someone else calls the endpoint with pure curl on their machine it will behave the same. So there was never a "it works on my machine".

[jcamiel]

Hi,

When we started coding Hurl (years ago before going open source on GitHub), we played with reqwest as the underlying HTTP engine.
We encountered an HTTP server that was sending a localized reason phrase, ie "200 succès" instead of "200 OK", something like:

HTTP/1.1 200 Succès
Connection: close
Content-Length: 7
Content-Type: text/html; charset=utf-8
Date: Tue, 05 Nov 2024 09:15:53 GMT

Searching for it, Tomcat 8.x used to respond with a response phrase and we encoutered instances where this reason phrase was localized...

At the time, the Rust component was panicking on this HTTP response, while curl happily returned the response without blicking. We realized the benefit of having a super robust HTTP library. Bonus point: debuging Hurl was (and is still) super easy, you just have to make the same curl command and see what's the difference. There was also a solid Rust crate that was doing the binding between libcurl and Rust, and cargo itself was using it (and is still using it as of today).

We switched to curl and, as @SilenLoc just says, it has been now a selling point of Hurl: it's just curl under the hood. Also, we were proposing a completly new file format and having a known reliable HTTP component allowed us to focused on the "icing cake".

Finally, important HTTP features are really super simple to implement:

• HTTP/3 is just one API call to libcurl, while some HTTP libraries are just beginning to support HTTP/2
• rate limiting, IPv6, proxy support etc... are just free to use

A final example is, for instance, the ability to use any curl options (provided they're in libcurl). Just doing this kind of request:

GET https://example.org/hello/../to/../your/../file

while the executed HTTP request is :

GET /hello/../to/../your/../file HTTP/1.1
Host: example.org
user-agent: curl/7.71.1
accept: */*

instead of

GET /file HTTP/1.1
Host: example.org
user-agent: curl/7.71.0
accept: */*

is possible in Hurl because we're exposing --path-as-is curl option.

So, very very very happy to rely on curl!