4 ms·

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 th

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.

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.