Hacker News Reader

Comment by AndrewStephens | Hacker News Reader

This is a great idea. A lot of people are going to say "why not use libcurl like everyone else?". Curl is great but this project is a better idea for client-side code.

libcurl is easy to integrate into C++ but hard to get right (this is not curl's fault). I see a lot of bad example code around the web that works(tm) but is not robust. I've seen so much bad curl code that I was moved to write[0] about some of the problems.

libcurl doesn't use OS-level features. It doesn't pick up the users proxy settings or use the cache or cookie store. This is sometimes what you want but for standard client apps Nfhttp's approach is better.

[0] https://sheep.horse/2019/3/using_libcurl_effectively_and_saf...

View on HN

I agree in general that using native HTTP stacks is a good idea for all sorts of reasons, but it's worth calling out that NFHTTP is actually using CURL under the hood on Linux & Android platforms so this just ultimately wraps the CURL C API in a C++ API. On OSX it is using NSURL which is great, and on Windows it's using Microsoft's cpprestsdk library in order to talk with WinHTTP and UWP.

I think that is acceptable on Linux where there is no system provided HTTP library - curl is pretty much the de facto standard there.

I am surprised about Android though. Is there really no built-in HTTP client in Android that they could use?

There is, but it's Java - they would have to write JNI. I don't think there's anything wrong with using CURL. Should probably be a bit careful about calling it "native" though.

I just don't really see the point to how they've gone about this. Cpprestsdk is already structured in a way where writing different native client impls for each platform is part of the design. So, rather than adding more native implementations there, they've put another layer on top of cpprestsdk, and added some new client implementations in this new library, and for others it calls down and uses cpprestsdk's existing implementations.

This seems to fragment things more than if they had simply contributed to (or even forked) Microsoft's project.

Honestly the biggest gain by using the platform API is that you get SSL support for free. Otherwise you have to cross compile OpenSSL for every android target you want to support and for a fat universal lib for iOS. Its a giant pain.

That was the reason I used the platform APIs in one app, and it is an awful mess.

Then people use Android 4.0 or Windows 2000/XP, and complain they cannot use TLS1.2. And you cannot use the platform defaults, or Android 4.x fails with TLS1.2, because it is not enabled in the defaults, despite being supported. So you enable TLS1.2 and all ciphers, and then Android 8 fails on TLS1.3 due to a trapdoor cipher. Every device trusts different CAs, so you cannot know if https will work, unless you include all the needed certs rather than using the platform certs. Or the platform API is just completely removed like Apache HttpComponents from Android, and you need to rewrite it.

I agree, curl is great but the API is very difficult to use. Self plug, I've built my own curl c++ wrapper [0] for making thousands of requests per second (libuv event loop driver) and I find a cleaner API gets new devs into it a lot easier. It's definitely far from feature complete but I get a lot of mileage out of it.

[0] https://github.com/jbaldwin/liblifthttp

Did you manage to map the LibUV memory model onto RAII?

Generally yes. You just 'move' pointers through the callbacks and expose RAII request objects to the end user, they don't see any of the ugliness underneath.

I have written some cross platform mobile apps with djinni and C++ and always use the platform Network interfaces. Its just so much easier than having to worry about SSL/TLS and getting curl to compile.

Reply on news.ycombinator.com