6 ms·

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-sid

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_safely_in_c%2B%2B.html https://sheep.horse/2019/3/using_libcurl_effectively_and_saf...

tele_ski 8y ago
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 https://github.com/jbaldwin/liblifthttp
- adgasf 8y ago
  Did you manage to map the LibUV memory model onto RAII?
  - tele_ski 8y ago
    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.
deeringc 8y ago
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.
- AndrewStephens 8y ago
  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?
  - deeringc 8y ago
    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.
- rhodysurf 8y ago
  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.
  - benibela 8y ago
    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.
rhodysurf 8y ago
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.

tele_ski 8y ago

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 https://github.com/jbaldwin/liblifthttp

adgasf 8y ago
Did you manage to map the LibUV memory model onto RAII?
- tele_ski 8y ago
  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.

deeringc 8y ago

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.

AndrewStephens 8y ago
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?
- deeringc 8y ago
  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.
rhodysurf 8y ago
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.
- benibela 8y ago
  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.

rhodysurf 8y ago

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.