WinINet jämfört med WinHTTP

Med några få undantag är WinINet en superuppsättning WinHTTP. När du väljer mellan de två bör du använda WinINet-om du inte planerar att köra i en tjänst- eller tjänstliknande process som kräver personifiering och sessionsisolering.

Jämförelse av funktioner

Funktion WinINet WinHTTP
cacheminne för autentiseringsuppgifter. Tillåter att alla inbyggda program i Windows Internet Explorer hämtar autentiseringsuppgifter automatiskt. Det gör också att ett program som körs utanför Internet Explorer kan fråga/ange autentiseringsuppgifterna för servern bara en gång. Från och med då är begäranden automatiska. Ja Nej
Uppmaning om autentiseringsuppgifter. Tillhandahåller ett API som gör att anropande kod kan fråga användaren om autentiseringsuppgifter. Ja Nej
FTP Ja Nej
stöd för autodial/RAS. Det här är äldre funktioner. Använd fjärråtkomst i stället. Ja Nej
zoner. Automatisk integrering med Internet Explorer-säkerhetszoner. Ja Nej
IDNA-stöd. Integrerat stöd för IDNA RFC/Punycode. Ja Ja
Cookie Jar-API:er. Beständiga och icke-beständiga cookies stöds. Alla program eller skript kan använda detta för att se samma cookies som webbläsaren. Ja Nej
IE-stöd för skyddat läge Ja Nej
Dekomprimeringsstöd. Stöd för gzip- och deflate-komprimeringsschema. Ja Ja
Stöd för uppdelad uppladdning. Klientkoden måste utföra segmenteringen. Nej Ja
SOCKS4 (SOCKS version 4) stöder. Innehåller inte v4a. Ja Nej
SOCKS5 (SOCKS version 5) stöder Nej Nej
Dubbelriktad skicka och ta emot Nej Nej
överlappad I/O Nej Nej
Stöd för filschema. Användbart för proxyskript med ett filschema. Ja Nej
InternetOpenUrl. Förenklad kod för att öppna en URL. Ja Nej
Servicesupport. Kan köras från en tjänst eller ett tjänstkonto. Nej Ja
Sessionsisolering. Separata sessioner påverkar inte varandra. Nej Ja
Imitation. Kan anropas medan tråden utger sig för att vara en annan användare. Nej Ja

Snabb beslutsguide

Använd det här flödesschemat för att välja rätt HTTP-klientstack:

  1. Körs koden i en Windows-tjänst, en systemprocess eller under en annan användares identitet?
    • Ja → Använda WinHTTP.
  2. Är din kod en skrivbordsapp som behöver användarens proxyinställningar för Internetalternativ (IE), cookies eller uppmaningar om autentiseringsuppgifter?
    • Ja → använda WinINet.
  3. Skriver du en modern C++-skrivbordsapp eller UWP/WinUI-app?
  4. Skriver du ett .NET program?
    • Ja → använd System.Net.Http.HttpClient.
  5. Behöver du plattformsoberoende kompatibilitet?
    • Ja → Använd libcurl eller ett liknande portabelt bibliotek.

Note

När du varken ska använda WinINet eller WinHTTP – Om du skapar ett nytt program och inte kräver äldre Win32-integrering föredrar du de moderna alternativ som anges ovan. De erbjuder enklare API:er och bättre asynkront stöd. Vissa alternativ erbjuder också ytterligare fördelar: libcurl och .NET HttpClient är plattformsoberoende; TLS 1.3-tillgänglighet beror på den underliggande TLS-stacken och OS-konfigurationen. Reservera WinHTTP/WinINet för scenarier som specifikt kräver Win32-tjänststöd, delning av webbläsarautentiseringsuppgifter eller djup proxyintegrering.

Important

Säkerhetspåminnelse – Oavsett vilken HTTP-stack du väljer inaktiverar du aldrig TLS-certifikatverifiering i produktion. Både WinHTTP och WinINet tillåter att certifikatfel ignoreras via flaggor, men det gör att ditt program utsätts för man-in-the-middle-attacker.

  • Last updated on