Partager via

Nouveautés de WinHTTP 5.1

  • Article

Cette rubrique décrit les différences les plus importantes entre WinHTTP version 5.1 et version 5.0. Bon nombre de ces différences nécessitent des modifications de code dans les applications migrées de la version 5.0 à la version 5.1. Certaines des fonctionnalités de la version 5.1 ne sont disponibles qu’à partir de Windows Server 2003 et Windows XP avec Service Pack 2 (SP2), en particulier celles liées à l’amélioration de la sécurité du client contre les serveurs Web malveillants.

Important

Avec la sortie de WinHTTP Version 5.1, le téléchargement de WinHTTP 5.0 n’est plus disponible. Depuis le 1er octobre 2004, Microsoft a supprimé le téléchargement du SDK WinHTTP 5.0 et a mis fin au support produit pour la version 5.0.

 

Changement de nom de la DLL

Le nom de la nouvelle DLL WinHTTP 5.1 est Winhttp.dll, alors que le nom de la DLL WinHTTP 5.0 est Winhttp5.dll.

WinHTTP 5.0 et 5.1 peuvent coexister sur le même système ; WinHTTP 5.1 ne remplace pas WinHTTP 5.0 et ne s’installe pas par-dessus.

Redistribution

WinHTTP 5.1 n’est disponible qu’avec Windows Server 2003, Windows 2000 Professionnel avec Service Pack 3 (SP3), Windows XP avec Service Pack 1 (SP1) et les systèmes d’exploitation ultérieurs. Un fichier module de fusion redistribuable (.msm) n’est pas disponible pour WinHTTP 5.1.

ProgID de WinHttpRequest

Le ProgID du composant WinHttpRequest est passé de « WinHttp.WinHttpRequest.5 » à « WinHttp.WinHttpRequest.5.1 ». Le CLSID de la classe WinHttpRequest a également changé.

Changement de comportement de rappel asynchrone

Lors de l’appel des fonctions WinHttpWriteData, WinHttpQueryDataAvailable et WinHttpReadData en mode asynchrone, ne comptez pas sur les paramètres OUT respectifs lpdwNumberOfBytesWritten, lpdwNumberOfBytesAvailable et lpdwNumberOfBytesRead pour être définis. Si l’appel de fonction se termine de manière asynchrone, WinHTTP n’écrit pas sur ces pointeurs fournis par le code de l’application. À la place, l’application doit récupérer ces valeurs en utilisant les paramètres lpvStatusInformation et dwStatusInformationLength dans la fonction de rappel.

Modifications des paramètres par défaut

Les modifications des paramètres par défaut incluent :

  • La vérification du certificat du serveur SSL est activée par défaut dans WinHTTP 5.1. WinHTTP 5.0 ne gère pas les échecs rencontrés lors de la validation du certificat du serveur comme des erreurs fatales ; ils sont signalés à l’application à l’aide d’une notification de rappel SECURE_FAILURE, mais ne provoquent pas l’abandon de la requête. WinHTTP 5.1, en revanche, traite les échecs de validation du certificat serveur comme des erreurs fatales qui annulent la requête. L’application peut demander à WinHTTP d’ignorer un petit sous-ensemble d’erreurs de certificat telles que CA inconnu, date de certificat invalide/expirée ou nom de sujet de certificat invalide, en utilisant l’option WINHTTP_OPTION_SECURITY_FLAGS.
  • La prise en charge de l’authentification Passport est désactivée par défaut dans WinHTTP 5.1. La prise en charge de Passport peut être activée avec l’option WINHTTP_OPTION_CONFIGURE_PASSPORT_AUTH. La recherche automatique des informations d’identification Passport dans le Keyring est également désactivée par défaut.
  • Changement de comportement de redirection : les redirections HTTP d’une URL sécurisée https: vers une URL régulière http: ne sont plus suivies automatiquement par défaut pour des raisons de sécurité. Il existe une nouvelle option, WINHTTP_OPTION_REDIRECT_POLICY, pour remplacer le comportement de redirection par défaut dans WinHTTP 5.1. Avec le composant COM WinHttpRequest, utilisez la nouvelle option WinHttpRequestOption_EnableHttpsToHttpRedirects pour activer les redirections des URL https: vers http:.
  • Lorsqu’un fichier de trace WinHTTP est créé, l’accès est restreint avec une ACL de telle sorte que seuls les administrateurs peuvent lire ou écrire dans le fichier. Le compte utilisateur sous lequel le fichier de trace a été créé peut également modifier l’ACL pour accorder l’accès à d’autres. Cette protection n’est disponible que sur les systèmes de fichiers prenant en charge la sécurité ; c’est-à-dire NTFS, pas FAT32).
  • À partir de Windows Server 2003 et Windows XP avec SP2, l’envoi de requêtes vers les ports non-HTTP bien connus suivants est restreint pour des raisons de sécurité : 21 (FTP), 25 (SMTP), 70 (GOPHER), 110 (POP3), 119 (NNTP), 143 (IMAP).
  • À partir de Windows Server 2003 et Windows XP avec SP2, la quantité maximale de données d’en-tête acceptée par WinHTTP dans une réponse HTTP est de 64K par défaut. Si la réponse HTTP du serveur contient plus de 64K de données d’en-tête totales, WinHTTP échoue à la requête avec une erreur ERROR_WINHTTP_INVALID_SERVER_RESPONSE. Cette limite de 64K peut être dépassée en utilisant la nouvelle option WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE.

Prise en charge d'IPv6

WinHTTP 5.1 ajoute la prise en charge de la version 6 du protocole Internet (IPv6). WinHTTP peut envoyer des requêtes HTTP à un serveur dont le nom DNS se résout en une adresse IPv6, et à partir de Windows Server 2003 et Windows XP avec SP2, WinHTTP prend également en charge les adresses littérales IPv6.

Nouvelles options dans l’API C/C++ pour WinHTTP

WinHTTP 5.1 implémente les nouvelles options suivantes :

« \#define WINHTTP\_OPTION\_PASSPORT\_SIGN\_OUT 86" "\#define WINHTTP\_OPTION\_PASSPORT\_RETURN\_URL 87" "\#define WINHTTP\_OPTION\_REDIRECT\_POLICY 88 »

À partir de Windows Server 2003 et Windows XP avec SP2, WinHTTP 5.1 implémente les nouvelles options suivantes. Cependant, sous Windows 2000 Professionnel avec SP3 ou Windows XP avec SP1, les appels à WinHttpSetOption ou WinHttpQueryOption avec ces ID d’option échouent :

« \#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 »

Nouvelles options dans le composant WinHttpRequest 5.1

Le composant WinHttpRequest 5.1 implémente les nouvelles options suivantes :

« WinHttpRequestOption\_RevertImpersonationOverSsl » « WinHttpRequestOption\_EnableHttpsToHttpRedirects » « WinHttpRequestOption\_EnablePassportAuthentication »

Les nouvelles options suivantes de WinHttpRequest 5.1 sont disponibles à partir de Windows Server 2003 et Windows XP avec SP2 :

« WinHttpRequestOption\_MaxAutomaticRedirects » « WinHttpRequestOption\_MaxResponseHeaderSize » « WinHttpRequestOption\_MaxResponseDrainSize » « WinHttpRequestOptions\_EnableHttp1\_1 »

Les proxys ne sont pas de confiance lorsque la sécurité de l’ouverture de session automatique est définie sur Élevée

Dans WinHTTP 5.0, les serveurs proxy sont toujours de confiance pour l’ouverture de session automatique. Cela n’est plus valable pour WinHTTP 5.1 fonctionnant sous Windows Server 2003 et Windows XP avec SP2 lorsque l’option de politique WINHTTP_AUTOLOGON_SECURITY_LEVEL_HIGH est définie.

API de découverte automatique de proxy Web (AutoProxy)

Pour faciliter la configuration des paramètres de proxy pour les applications basées sur WinHTTP, WinHTTP implémente désormais le protocole Web Proxy Auto-Discovery (WPAD), également appelé autoproxy. Il s’agit du même protocole que les navigateurs Web, tels qu’Internet Explorer, implémentent pour découvrir automatiquement la configuration du proxy sans nécessiter que l’utilisateur final spécifie manuellement un serveur proxy. Pour prendre en charge l’autoproxy, WinHTTP 5.1 implémente une nouvelle fonction C/C++, WinHttpGetProxyForUrl, ainsi que deux fonctions de support, WinHttpDetectAutoProxyConfigUrl et WinHttpGetIEProxyConfigForCurrentUser.

Problèmes connus

Les problèmes suivants sont connus pour exister dans WinHTTP 5.1 sur Windows 2000 Professionnel avec SP3 et Windows XP avec SP1. Ces problèmes sont résolus pour WinHTTP à partir de Windows Server 2003 et Windows XP avec SP2 :

  • Si l’application utilise la fonction WinHttpSetTimeouts ou la méthode SetTimeouts sur le composant WinHttpRequest pour définir un délai de résolution DNS non infini tel que le paramètre dwResolveTimeout, une fuite de handle de thread se produit chaque fois que WinHTTP résout un nom DNS. Sur un grand nombre de requêtes HTTP, cela entraîne une fuite de mémoire importante. La solution consiste à laisser le paramètre de délai de résolution infini par défaut inchangé (une valeur de 0 spécifie un délai infini). Cela est fortement recommandé de toute façon car la prise en charge des délais d’expiration sur les résolutions de noms DNS dans WinHTTP est coûteuse en termes de performance. Pour Windows 2000 et versions ultérieures, définir un délai d’expiration de résolution DNS dans WinHTTP est inutile car le service client DNS sous-jacent implémente son propre délai d’expiration de résolution.
  • Lors du traitement des requêtes asynchrones, WinHTTP ne gère pas correctement l’usurpation de thread. Cela provoque l’échec des requêtes nécessitant une authentification NTLM/Négocier, à moins que les informations d’identification ne soient explicitement fournies en utilisant les fonctions WinHttpSetCredentials ou WinHttpSetOption.