Delphi: TIdHTTP vs TNetHTTPClient

Question

I'm writing a download manager in Delphi with some custom features like resumable downloads and downloading through proxies.

I'm studing different component solutions: Indy and NetHTTP, both seem very close.

• TNetHTTPClient seem to be an interface of winhttp.dll.

• TIdHTTP seem to be an interface of wininet.dll (but i'm not sure).

• TIdHTTP seems like a very old component (maybe very stable/tested) and has tons of documentation online.

• TNetHTTPClient seems to be a very recent component, and doesn't have good documentation online.

I'm a bit undecided... which one to choose?

The point is: what is the main difference between these two components?

My question is a bit disputable (primarily opinion-based), but I haven't found any practical comparison between these two components.

Newsdealer

Answer 1

Indy DOES NOT use WinInet/WinHTTP at all. It uses cross-platform BSD/POSIX based socket APIs directly (like WinSock on Windows), implementing Internet protocols (like HTTP) completely from scratch.

TIdHTTP is a manual HTTP implementation.

TNetHTTPClient, on the other hand, wraps system-provided HTTP APIs instead (like WinInet/WinHTTP on Windows).

Eventempered

Which is the faster and more reliable from TNetHTTPClient and TIdHTTP? I've use always idHTTP, but from my benchmarks TNetHTTPClient seems to be faster – Siphonophore

@CescoBagnoli I can't answer that. We never did any kind of benchmark comparisons like that. – Eventempered

Answer 2

TNetHTTPClient was introduced in Delphi XE8.

The most important benefit of TNetHTTPClient is that it allows your application to support HTTPS without having to provide your own support for SSL/TLS. TNetHTTPClient relies on the SSL/TLS support provided by the operating system.

This means you don't have to update your application whenever new vulnerabilities are discovered. Your customers will get these updates as part of their operating system updates. Less work for you and better security for your customers (if they believe their operating system vendor to be better at updating SSL/TLS libraries than you are).

It also means the code that encrypts and decrypts the HTTPS traffic is not in your application. So your application is not affected by restrictions on importing or exporting encryption algorithms.

TIdHTTP relies on OpenSSL to support HTTPS. You'll have to ship two DLLs with your application. OpenSSL is an open source project. Some organizations have issues with software that contains open source components. One of our products uses TIdFTP and OpenSSL to support FTPS. Every now and then we have users asking if the product will work without these DLLs (it will, but without FTPS), because their presence makes it more difficult to get the software approved for use at their organization.

I believe that all this was also Embarcadero's motivation for creating TNetHTTPClient (even though they already had TIdHTTP). It moves the onus of making sure HTTPS is secure from the developer to the operating system.

Darmit

"TIdHTTP relies on OpenSSL to support HTTPS" - actually, it merely defaults to OpenSSL, because that is the default implementation bundled with Indy. But technically, it does not require OpenSSL at all. You can use whatever SSL/TLS library you want, all you need is to wrap it inside a TIdSSLIOHandlerSocketBase-derived class that you can then attach to TIdHTTP (or any other TCP-based component). Eldos SecureBlackbox provides such a wrapper class for its SSL/TLS engine, for example. And Indy's team has an SChannel wrapper in the works as an alternative to OpenSSL on Windows. – Eventempered

I've used both the OpenSSL and Eldos SBB that Remy mentioned with TIdHTTP. Eldos is a little expensive but is nice because it compiles everything in and does not use extra DLLs. – Nevsa

One big problem I ran into with relying on WinInet/WinHttp was that I could not find a way to set the protocols used on an application basis. It appeared that you had to set the protocols for the OS and then you were stuck with that. It may just be due to my ignorance though. – Nevsa