If you want to implement an HTTP client access in your application, you may consider several choices:
- Use the provided Indy components;
- Use third-party components like Synapse, ICS or your own WinSock-based wrapper;
- Use WinINet;
- Use WinHTTP.
For our ORM, we tried to avoid external dependencies, and did not have the need of all Indy's features and overhead.
We fist wrote our own WinSock wrapper, then tried out WinInet.
When used on our testing benchmark, we found out that WinINet was dead slow.
Then we tried WinHTTP, the new API provided by Microsoft, and we found out this was blazing fast. As fast as direct WinSock access, without the need of writing all the wrapper code.
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
orTSQLite3HttpClientWinHTTP
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) andTSQLite3HttpClientWinHTTP
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, callnetsh
or proxycfg
bits from %SystemRoot%SysWOW64
folder explicitly.
Conclusion
As stated above, there is still a potential performance issue to use the directTSQLite3HttpClientWinSock
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 theTSQLite3HttpClientWinHTTP
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 WinInetor WinHttp.
See our source code repository.WinInet Introduction
This tutorial guides you through basics of WinInet including how to use WinInet with HTTP, FTP, and Gopher protocols with real world examples.
There are five chapters in this tutorial.
- Introduction to WinInet.
- Working with Common WinInet APIs.
- WinInet APIs for HTTP and FTP with sample examples.
- WinInet MFC classes with sample examples.
- Advanced WinInet and Security Issues.
Prerequisites: Windows API, MFC, OOP, basics of the Internet such as URL, protocols, HTTP, FTP, TCP/IP etc.
Internet Applications
Today, the web programming is a basic need for a developer. Starting from a manufacturing to engineering, document to e-commerce, every business is moving towards the Internet. Why wouldn't be? It’s easy to access, anywhere, anytime. You don't have to carry data with you. Just upload your data on one web server and you can access anywhere in the world.
Let's see a typical Internet application. Basically, there are three parts of an Internet application: the client (GUI interface), Server (Dlls, ASP, Database, or CGI), and communication between the client and the server (protocol).
Here is a typical Internet application model:
Internet Protocols
A protocol is a set of rules, which is required to communicate between two computers. Both computers must understand and implement these rules to talk to each other.
Application-level Internet Protocols
The Client and the server applications communicate one another via application-level protocols.
All application-level protocols are built on top of TCP/IP, which consists of lower-level protocols that provide the application-level protocol with a mechanism for reliable data transmission between computers. Every protocol has a port number, which is used to decide what protocol is used for connection. Here is a list of port numbers for various standard protocols:
Clients
It's a GUI Windows application with ability to communicate to server with the help of protocols. Clients use APIs to communicate with the servers.
Windows provides two kind of network APIs, WinInet and WinSock. The WinInet is an application-level API and supports only HTTP, FTP, and Gopher protocols. While WinSock is set of low-level APIs and supports most of the protocols described above.
Server Components
Server components typically sit on the web server to extend its functionality. Each component performs a specific task such as reading/writing to the database, performing calculations etc. These components are ASP, ISAPI dlls, or CGI scripts.
WinInet Vs. WinSock
- WinInet provides a higher level-programming interface, which is easy to use while WinSock, is a low level interface, which is hard to implement. To implement WinSock, you should have some knowledge of Windows Sockets and TCP/IP. While WinInet hides this all from developers and does every thing under the hood.
- WinInet provides support for only three protocols - HTTP, FTP, and Gopher while WinSock let you work with most of the protocols.
- WinInet supports build-in-caching which improves downloading performance.
- WinInet provides easy connections and has support for proxy servers.
- WinInet provides more security over WinSock.
Basically choosing between WinInet and WinSock is pretty easy. If your application needs to access HTTP, FTP, or Gopher protocols then WinInet is better choice, whille WinSock is for rest.
What is WinInet?
WinInet is high level, easy-to-use API to work with HTTP, FTP, and Gopher protocols. If you use WinInet, you don't have to worry about learning protocol specifications such as TCP/IP or Windows Sockets.
When to use WinInet?
Using HTTP, FTP, and gopher
- Download web pages, images, sounds, and video files.
- Execute server files such as CGI scripts, ISAPI dlls, or ASP scripts.
- Access remote database and file systems.
- Perform web searches.
- Download and Upload files between computers.
As you will walk through this tutorial, you will see how easy is working with WinInet and Internet protocols.
Other chapters of this tutorial
- Working with Common WinInet APIs.
- WinInet APIs for HTTP and FTP with sample examples.
- WinInet MFC classes with sample examples.
If you want to implement an HTTP client access in your application, you may consider several choices:
- Use the provided Indy components;
- Use third-party components like Synapse, ICS or your own WinSock-based wrapper;
- Use WinINet;
- Use WinHTTP.
For our ORM, we tried to avoid external dependencies, and did not have the need of all Indy's features and overhead.
We fist wrote our own WinSock wrapper, then tried out WinInet.
When used on our testing benchmark, we found out that WinINet was dead slow.
Then we tried WinHTTP, the new API provided by Microsoft, and we found out this was blazing fast. As fast as direct WinSock access, without the need of writing all the wrapper code.
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
orTSQLite3HttpClientWinHTTP
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) andTSQLite3HttpClientWinHTTP
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, callnetsh
or proxycfg
bits from %SystemRoot%SysWOW64
folder explicitly.
Conclusion
As stated above, there is still a potential performance issue to use the directTSQLite3HttpClientWinSock
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 theTSQLite3HttpClientWinHTTP
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 WinInetor WinHttp.
See our source code repository.