Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
I det här avsnittet beskrivs de viktigaste skillnaderna mellan WinHTTP version 5.1 och version 5.0. Många av dessa skillnader kräver kodändringar i program som migrerar från version 5.0 till version 5.1. Vissa av funktionerna i version 5.1 är endast tillgängliga från och med Windows Server 2003 och Windows XP med Service Pack 2 (SP2), särskilt funktioner som rör att förbättra klientens säkerhet mot skadliga webbservrar.
Viktig
Med lanseringen av WinHTTP Version 5.1 är WinHTTP 5.0-nedladdningen inte längre tillgänglig. Från och med den 1 oktober 2004 har Microsoft tagit bort nedladdningen av WinHTTP 5.0 SDK och har avslutat produktsupporten för version 5.0.
Namnändring för DLL
Namnet på den nya WinHTTP 5.1-DLL:n är Winhttp.dll, medan namnet på DLL:n WinHTTP 5.0 är Winhttp5.dll.
WinHTTP 5.0 och 5.1 kan samexistera i samma system. WinHTTP 5.1 ersätter inte, eller installerar över, WinHTTP 5.0.
Omfördelning
WinHTTP 5.1 är endast tillgängligt med Windows Server 2003, Windows 2000 Professional med Service Pack 3 (SP3), Windows XP med Service Pack 1 (SP1) och senare operativsystem. En omdistribuerbar kopplingsmodulfil (.msm) är inte tillgänglig för WinHTTP 5.1.
WinHttpRequest ProgID
ProgID för WinHttpRequest-komponenten har ändrats från "WinHttp.WinHttpRequest.5" till "WinHttp.WinHttpRequest.5.1". CLSID för klassen WinHttpRequest har också ändrats.
Beteendeändring för asynkron callback
När du anropar funktionerna WinHttpWriteData, WinHttpQueryDataAvailable och WinHttpReadData i asynkront läge, förlita dig inte på respektive lpdwNumberOfBytesWritten, lpdwNumberOfBytesAvailableoch lpdwNumberOfBytesRead OUT-parametrar som ska anges. Om funktionsanropet slutförs asynkront skriver WinHTTP inte till de pekare som tillhandahålls av programkoden. I stället ska programmet hämta dessa värden med hjälp av lpvStatusInformation och dwStatusInformationLength parametrar till återanropsfunktionen.
Ändringar i standardinställningar
Ändringar i standardinställningarna är:
- SSL-servercertifikatverifiering är aktiverat som standard i WinHTTP 5.1. WinHTTP 5.0 hanterar inte fel som påträffas när servercertifikatet verifieras som allvarliga fel. de rapporteras till programmet med hjälp av ett SECURE_FAILURE återanropsmeddelande, men gör inte att begäran avbryts. WinHTTP 5.1 hanterar också verifieringsfel för servercertifikat som allvarliga fel som avbryter begäran. Programmet kan instruera WinHTTP att ignorera en liten delmängd av certifikatfel som okänd certifikatutfärdare, ogiltigt/utgånget certifikatdatum eller ogiltigt certifikatmottagarenamn med hjälp av alternativet WINHTTP_OPTION_SECURITY_FLAGS.
- Stöd för Passport-autentisering är inaktiverat som standard i WinHTTP 5.1. Passport-stöd kan aktiveras med alternativet WINHTTP_OPTION_CONFIGURE_PASSPORT_AUTH. Automatisk uppslagning av Passport-autentiseringsuppgifter i Keyring är också inaktiverad som standard.
- Ändring av omdirigeringsbeteende: HTTP-omdirigeringar från en säker https: URL till en vanlig http: URL följs inte längre automatiskt för standardinställningar av säkerhetsskäl. Det finns ett nytt alternativ, WINHTTP_OPTION_REDIRECT_POLICY, för att åsidosätta standardbeteendet för omdirigering i WinHTTP 5.1. Med WinHttpRequest COM-komponenten använder du det nya WinHttpRequestOption_EnableHttpsToHttpRedirects alternativet för att aktivera omdirigeringar från https: till http: URL:er.
- När en WinHTTP-spårningsfil skapas begränsas åtkomsten med en ACL så att endast administratörer kan läsa eller skriva filen. Användarkontot under vilket spårningsfilen skapades kan också ändra ACL:en för att ge andra åtkomst. Det här skyddet är endast tillgängligt för filsystem som stöder säkerhet. det vill: NTFS, inte FAT32).
- Från och med Windows Server 2003 och Windows XP med SP2 är sändning av begäranden till följande välkända portar som inte är HTTP begränsade av säkerhetsskäl: 21 (FTP), 25 (SMTP), 70 (GOPHER), 110 (POP3), 119 (NNTP), 143 (IMAP).
- Från och med Windows Server 2003 och Windows XP med SP2 är den maximala mängden sidhuvuddata som WinHTTP accepterar i ett HTTP-svar 64 000 som standard. Om serverns HTTP-svar innehåller mer än 64 000 totalt sidhuvuddata misslyckas WinHTTP med ett ERROR_WINHTTP_INVALID_SERVER_RESPONSE fel. Den här 64K-gränsen kan åsidosättas med det nya alternativet WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE.
IPv6-support
WinHTTP 5.1 lägger till stöd för Internet Protocol Version 6 (IPv6). WinHTTP kan skicka HTTP-begäranden till en server vars DNS-namn matchas till en IPv6-adress och från och med Windows Server 2003 och Windows XP med SP2 stöder WinHTTP även IPv6-literaladresser.
Nya alternativ i C/C++-API:et för WinHTTP
WinHTTP 5.1 implementerar följande nya alternativ:
- \#define WINHTTP\_OPTION\_PASSPORT\_SIGN\_OUT 86
\#define WINHTTP\_OPTION\_PASSPORT\_RETURN\_URL 87
\#define WINHTTP\_OPTION\_REDIRECT\_POLICY 88
Från och med Windows Server 2003 och Windows XP med SP2 implementerar WinHTTP 5.1 följande nya alternativ. I Windows 2000 Professional med SP3 eller Windows XP med SP1 misslyckas dock anrop till WinHttpSetOption eller WinHttpQueryOption med följande alternativ-ID:
- "\#define WINHTTP\_OPTION\_RECEIVE\_RESPONSE\_TIMEOUT 7" "\#define WINHTTP\_OPTION\_MAX\_HTTP\_AUTOMATIC\_REDIRECTS 89" "\#define WINHTTP\_OPTION\_MAX\_HTTP\_STATUS\_CONTINUE 90" "\#define WINHTTP\_OPTION\_MAX\_RESPONSE\_HEADER\_SIZE 91" "\#define WINHTTP\_OPTION\_MAX\_RESPONSE\_DRAIN\_SIZE 92"
Nya alternativ i WinHttpRequest 5.1-komponenten
Komponenten WinHttpRequest 5.1 implementerar följande nya alternativ:
- "WinHttpRequestOption\_RevertImpersonationOverSsl" "WinHttpRequestOption\_EnableHttpsToHttpRedirects" "WinHttpRequestOption\_EnablePassportAuthentication"
Följande nya WinHttpRequest 5.1-alternativ är tillgängliga från och med Windows Server 2003 och Windows XP med SP2:
- "WinHttpRequestOption\_MaxAutomaticRedirects" "WinHttpRequestOption\_MaxResponseHeaderSize" "WinHttpRequestOption\_MaxResponseDrainSize" "WinHttpRequestOptions\_EnableHttp1\_1"
Proxyservrar är inte betrodda när säkerheten för automatisk inloggning är inställd på Hög
I WinHTTP 5.0 är proxyservrar alltid betrodda för automatisk inloggning. Detta är inte längre giltigt för WinHTTP 5.1 som körs på Windows Server 2003 och Windows XP med SP2 när WINHTTP_AUTOLOGON_SECURITY_LEVEL_HIGH principalternativet har angetts.
API för automatisk identifiering av webbproxy
För att underlätta konfigurationen av proxyinställningar för WinHTTP-baserade program implementerar WinHTTP nu WPAD-protokollet (Web Proxy Auto-Discovery), även kallat autoproxy. Det här är samma protokoll som webbläsare, till exempel Internet Explorer, implementerar för att identifiera proxykonfigurationen automatiskt utan att en slutanvändare behöver ange en proxyserver manuellt. För att stödja autoproxy implementerar WinHTTP 5.1 en ny C/C++-funktion, WinHttpGetProxyForUrlplus två stödfunktioner, WinHttpDetectAutoProxyConfigUrl och WinHttpGetIEProxyConfigForCurrentUser.
Kända problem
Följande problem är kända för att finnas i WinHTTP 5.1 på Windows 2000 Professional med SP3 och Windows XP med SP1. De här problemen är lösta för WinHTTP från och med Windows Server 2003 och Windows XP med SP2:
- Om programmet använder funktionen WinHttpSetTimeouts eller metoden SetTimeouts på komponenten WinHttpRequest för att ange en tidsgräns för icke-oändlig DNS-matchning, till exempel dwResolveTimeout parameter, uppstår en läcka i trådhandtaget varje gång WinHTTP löser ett DNS-namn. Över ett stort antal HTTP-begäranden orsakar detta en betydande minnesläcka. Lösningen är att lämna standardinställningen för oändlig lösnings-timeout oförändrad (värdet 0 anger en oändlig timeout). Detta rekommenderas i alla fall eftersom det är dyrt att stödja tidsgränser för DNS-namnmatchningar i WinHTTP när det gäller prestanda. För Windows 2000 och senare är det onödigt att ange tidsgränsen för DNS-matchning i WinHTTP eftersom den underliggande DNS-klienttjänsten implementerar sin egen timeout för att lösa problemet.
- Vid bearbetning av asynkrona begäranden hanterar WinHTTP inte trådimitation korrekt. Detta gör att begäranden som kräver NTLM/Negotiate-autentisering misslyckas, såvida inte autentiseringsuppgifter uttryckligen anges med hjälp av funktionerna WinHttpSetCredentials eller WinHttpSetOption.