About WinHTTP
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
In fact, there are several implementation of a HTTP/1.1 client available in
our ORM, according to this class hierarchy:
So you can select either TSQLite3HttpClientWinSock
,
TSQLite3HttpClientWinINet
or
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
name, TSQLite3HttpClientWinSock
will call directly the
WinSock API, TSQLite3HttpClientWinINet
will call
WinINet API (as used by IE 6) and
TSQLite3HttpClientWinHTTP
will cal the latest WinHTTP
API:
- 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:
Criteria | WinSock | WinINet | WinHTTP |
API Level | Low | High | Medium |
Local speed | Fastest | Slow | Fast |
Network speed | Slow | Medium | Fast |
Minimum OS | Win95/98 | Win95/98 | Win2000 |
HTTPS | Not available | Available | Available |
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 proxycfg.exe
on Windows XP and Windows Server 2003 or earlier, either netsh.exe
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 netsh
or proxycfg
bits from %SystemRoot%SysWOW64
folder explicitly.
Conclusion
As stated above, there is still a potential performance issue to use the
direct TSQLite3HttpClientWinSock
class over a network. It has been
reported on our forum, and root cause was not identified yet.
Therefore, the 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.