Here is how Microsoft defines WinHTTP:
Microsoft Windows HTTP Services (WinHTTP) provides developers with a server-supported, high-level interface to the HTTP/1.1 Internet protocol. WinHTTP is designed to be used primarily in server-based scenarios by server applications that communicate with HTTP servers.
WinINet was designed as an HTTP client platform for interactive desktop applications, such as Microsoft Internet Explorer, Microsoft Office, and Microsoft Money. WinINet displays a user interface for some operations such as collecting user credentials. WinHTTP, however, handles these operations programmatically. Server applications that require HTTP client services should use WinHTTP instead of WinINet. For more information, see Porting WinINet Applications to WinHTTP.
WinHTTP is also designed for use in system services and HTTP-based client applications. However, single-user applications that require FTP protocol functionality, cookie persistence, caching, automatic credential dialog handling, Internet Explorer compatibility, or downlevel platform support should consider using WinINet.
Classes provided by our framework
So you can select either
TSQLite3HttpClientWinHTTP for a HTTP/1.1 client.
Each class has its own architecture, and attaches itself to a Windows
communication library, all based on WinSock API. As stated by their
TSQLite3HttpClientWinSock will call directly the
TSQLite3HttpClientWinINet will call
WinINet API (as used by IE 6) and
TSQLite3HttpClientWinHTTP will cal the latest WinHTTP
- WinSock is the common user-space API to access the sockets stack of Windows, i.e. IP connection - it's able to handle any IP protocol, including TCP/IP, UDP/IP, and any protocol over it (including HTTP);
- WinINet was designed as an HTTP API client platform that allowed the use of interactive message dialogs such as entering user credentials - it's able to handle HTTP and FTP protocols;
- WinHTTP's API set is geared towards a non-interactive environment allowing for use in service-based applications where no user interaction is required or needed, and is also much faster than WinINet - it only handles HTTP protocol.
Here are some PROs and CONs of those solutions:
|Integration with IE||None||Excellent (proxy)||Available (see below)|
|User interactivity||None||Excellent (authentication, dial-up)||None|
How to retrieve the proxy settings for WinHTTP
Note that even if WinHTTP does not share by default any proxy
settings with Internet Explorer, it can import the current IE settings. The
WinHTTP proxy configuration is set by either
on Windows XP and Windows Server 2003 or earlier, either
on Windows Vista and Windows Server 2008 or later; for instance, you can run
proxycfg -u" or "
netsh winhttp import proxy
source=ie" to use the current user's proxy settings for Internet
Explorer. Under 64 bit Vista/Seven, to configure applications using the 32 bit
WinHttp settings, call
%SystemRoot%SysWOW64 folder explicitly.
As stated above, there is still a potential performance issue to use the
TSQLite3HttpClientWinSock class over a network. It has been
reported on our forum, and root cause was not identified yet.
TSQLite3HttpClient class maps by default to the
TSQLite3HttpClientWinHTTP class. This is the recommended usage
from a Delphi client application.
In practice, we found out that WinHTTP was definitively fast and stable. If your application still relay on WinInet, you may consider using WinHTTP instead.
Our SynCrtSock unit provides all necessary classes for access to
either WinInet or WinHttp.
See our source code repository.
Feedback are welcome on our forum.