Edit

WinINet vs. WinHTTP

  • Article

With a few exceptions, WinINet is a superset of WinHTTP. When you're choosing between the two, you should use WinINet unless you plan to run within a service or service-like process that requires impersonation and session isolation.

Comparison of features

Feature WinINet WinHTTP
Credential cache. Allows all built-in applications in Windows Internet Explorer to get credentials automatically. It also allows an application running outside of Internet Explorer to prompt/specify the credentials for the server only once. From then on the requests are automatic. yes no
Credential prompting. Provides an API that allows the calling code to prompt the user for credentials. yes no
FTP yes no
Autodial/RAS support. This is legacy functionality. Use Remote Access instead. yes no
Zones. Automatic integration with Internet Explorer security zones. yes no
IDNA support. Integrated support for the IDNA RFC/Punycode. yes yes
Cookie Jar APIs. Persistent and non-persistent cookies are supported. Any application or script can use this to see the same cookies as the browser. yes no
Protected mode IE support yes no
Decompression support. Support for gzip and deflate compression scheme. yes yes
Chunked upload support. Client code must perform the chunking. no yes
SOCKS4 (SOCKS version 4) support. Doesn't include v4a. yes no
SOCKS5 (SOCKS version 5) support no no
Bidirectional send and receive no no
Overlapped I/O no no
File scheme support. Useful for proxy scripts with a file scheme. yes no
InternetOpenUrl. Simplified code to open a URL. yes no
Services support. Can be run from a service or a service account. no yes
Session isolation. Separate sessions do not impact each other. no yes
Impersonation. Supports being called while the thread is impersonating a different user. no yes