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. La plupart de ces différences nécessitent des modifications de code dans les applications qui migrent de la version 5.0 vers la version 5.1. Certaines des fonctionnalités de la version 5.1 sont disponibles uniquement à partir de Windows Server 2003 et Windows XP avec Service Pack 2 (SP2), en particulier les fonctionnalités liées à l’amélioration de la sécurité du client contre des serveurs Web malveillants.

Important

Avec la version 5.1 de WinHTTP, 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 Kit de développement logiciel (SDK) WinHTTP 5.0 à partir de MSDN et a mis fin au support produit pour la version 5.0.

 

Changement de nom de DLL

Le nom de la nouvelle DLL WinHTTP 5.1 est Winhttp.dll, tandis 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 l’installe pas.

Redistribution

WinHTTP 5.1 est disponible uniquement 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 de module de fusion redistribuable (.msm) n’est pas disponible pour WinHTTP 5.1.

WinHttpRequest ProgID

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

Modification du comportement de rappel asynchrone

Lorsque vous appelez les fonctions WinHttpWriteData, WinHttpQueryDataAvailable et WinHttpReadData en mode asynchrone, ne vous fiez pas aux paramètres lpdwNumberOfBytesWritten,lpdwNumberOfBytesAvailable et lpdwNumberOfBytesRead OUT respectifs à définir. Si l’appel de fonction se termine de manière asynchrone, WinHTTP n’écrit pas dans ces pointeurs fournis par le code de l’application. Au lieu de cela, l’application doit récupérer ces valeurs à l’aide des paramètres lpvStatusInformation et dwStatusInformationLength pour la fonction de rappel.

Modifications apportées aux paramètres par défaut

Les modifications apportées aux paramètres par défaut sont les suivantes :

  • La vérification du certificat de 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 de serveur comme des erreurs irrécupérables ; ils sont signalés à l’application à l’aide d’une notification de rappel SECURE_FAILURE , mais ne provoque pas l’abandon de la demande. WinHTTP 5.1 gère également les échecs de validation de certificat de serveur comme des erreurs irrécupérables qui abandonnent la demande. L’application peut demander à WinHTTP d’ignorer un petit sous-ensemble d’erreurs de certificat, telles que l’autorité de certification inconnue, la date de certificat non valide/expirée ou le nom de l’objet du certificat non valide, à l’aide de 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 porte-clés est également désactivée par défaut.
  • Changement de comportement de redirection : les redirections HTTP d’une URL https: sécurisée vers une URL http: standard 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 de https: vers http: URL.
  • Lorsqu’un fichier de trace WinHTTP est créé, l’accès est limité avec une liste de contrôle d’accès de sorte que seuls les administrateurs puissent lire ou écrire le fichier. Le compte d’utilisateur sous lequel le fichier de trace a été créé peut également modifier la liste de contrôle d’accès pour accorder à d’autres utilisateurs l’accès. Cette protection est disponible uniquement sur les systèmes de fichiers qui prennent en charge la sécurité ; c’est-à-dire NTFS, pas FAT32).
  • À compter de Windows Server 2003 et Windows XP avec SP2, l’envoi de requêtes aux ports non HTTP connus suivants est limité pour des raisons de sécurité : 21 (FTP), 25 (SMTP), 70 (GOPHER), 110 (POP3), 119 (NNTP), 143 (IMAP).
  • À compter de Windows Server 2003 et de Windows XP avec SP2, la quantité maximale de données d’en-tête que WinHTTP accepte dans une réponse HTTP est de 64 Ko par défaut. Si la réponse HTTP du serveur contient plus de 64 000 données d’en-tête totales, WinHTTP échoue à la requête avec une erreur de ERROR_WINHTTP_INVALID_SERVER_RESPONSE . Cette limite de 64 Ko peut être remplacée à l’aide de la nouvelle option WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE .

Prise en charge d’IPv6

WinHTTP 5.1 ajoute la prise en charge du protocole Internet version 6 (IPv6). WinHTTP peut envoyer des requêtes HTTP à un serveur dont le nom DNS est résolu en adresse IPv6, et à compter 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 »

À compter de Windows Server 2003 et Windows XP avec SP2, WinHTTP 5.1 implémente les nouvelles options suivantes. Toutefois, sur 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 WinHttpRequest 5.1 suivantes 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 approuvés lorsque la sécurité d’ouverture de session automatique est définie sur Élevée

Dans WinHTTP 5.0, les serveurs proxy sont toujours approuvés pour l’ouverture de session automatique. Cela n’est plus valide pour WinHTTP 5.1 exécuté sur Windows Server 2003 et Windows XP avec SP2 lorsque l’option de stratégie 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 winHTTP, WinHTTP implémente désormais le protocole WPAD (Web Proxy Auto-Discovery), également appelé autoproxy. Il s’agit du même protocole que les navigateurs web, tels que les Explorer Internet, implémentent pour découvrir automatiquement la configuration du proxy sans nécessiter qu’un utilisateur final spécifie manuellement un serveur proxy. Pour prendre en charge autoproxy, WinHTTP 5.1 implémente une nouvelle fonction C/C++, WinHttpGetProxyForUrl, ainsi que deux fonctions de prise en charge, 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 provoque une fuite de mémoire importante. La solution de contournement consiste à laisser le paramètre de délai d’expiration de résolution infinie par défaut inchangé (une valeur de 0 spécifie un délai d’expiration infini). Cela est fortement recommandé dans tous les cas, 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 performances. Pour Windows 2000 et versions ultérieures, la définition d’un délai d’expiration de résolution DNS dans WinHTTP n’est pas nécessaire, car le service client DNS sous-jacent implémente son propre délai d’expiration de résolution.
  • Lors du traitement des demandes asynchrones, WinHTTP ne gère pas correctement l’emprunt d’identité de thread. Cela entraîne l’échec des demandes qui nécessitent l’authentification NTLM/Negotiate, sauf si les informations d’identification sont explicitement fournies à l’aide des fonctions WinHttpSetCredentials ou WinHttpSetOption .