Delphi: TIdHTTP vs TNetHTTPClient

问题:

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.

回答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).

回答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.