Synopse Open Source

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:

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.