WinInet n’est pas pris en charge dans un service ou une application IIS

Les fonctions Internet Microsoft Win32 (exportées à partir de WinInet.dll) ne sont pas prises en charge lorsqu’elles sont exécutées à partir d’un service ou d’une application IIS (également un service). Cet article décrit l’utilisation de la WinInet.dll dans un service ou dans des applications IIS.

Version d’origine du produit : Internet Explorer
Numéro de la base de connaissances d’origine : 238425

Informations supplémentaires

Étant donné que IIS est un service, vous aurez le même ensemble de problèmes lors de l’exécution de WinInet dans une extension ISAPI (Internet Server Application Program Interface) ou dans une DLL COM (DLL ActiveX) utilisée par ASP (Active Server Pages) que lors de l’exécution de WinInet dans un service. L’exécution de WinInet dans une application IIS présente également un ensemble unique de problèmes.

Le problème avec l’exécution de WinInet dans un service est que WinInet utilise les paramètres du registre pour les informations SSL, les informations de proxy, etc. Les services ne chargent pas la ruche du HKEY_CURRENT_USER Registre. Ces informations ne sont donc pas disponibles.

Les API WinInet signalent les violations d’accès lorsqu’elles sont utilisées à partir du service via le protocole SSL avec Internet Explorer 5.0 installé.

Pour comprendre les limitations propres à l’utilisation de WinInet dans un environnement serveur, il est nécessaire de comprendre l’historique de WinInet. WinInet a été développé pour être utilisé par internet Explorer. En fait, pour utiliser des versions ultérieures de WinInet, vous devez charger une installation minimale d’Internet Explorer. WinInet expose également des API destinées à être utilisées par d’autres applications clientes qui souhaitent accéder à des ressources sur Internet (ou intranet). Il est important de reconnaître l’environnement dans lequel WinInet a été développé et testé afin de comprendre l’utilisation appropriée de la DLL. WinInet a été développé pour une utilisation dans un environnement client. Bien qu’il agisse toujours en tant que client lorsqu’il s’exécute dans une DLL ISAPI, il s’exécute dans un environnement serveur dans ce cas.

Environnement client : personne exécutant internet Explorer

• Nombre de demandes relativement faible
• Demandes effectuées de façon relativement consécutive
• La durée de vie de l’application hôte est courte (durée de la session du navigateur)

Environnement de serveur : un serveur web (par exemple https://www.microsoft.com, )

• Nombre élevé de demandes par seconde
• Plusieurs threads effectuant des requêtes simultanément
• Doit s’exécuter pendant des semaines ou des mois

La solution recommandée consiste à utiliser WinHttp, qui est conçu pour s’exécuter dans un environnement de service, et comme il s’agit d’une pile HTTP côté serveur, elle n’est pas liée à la limite de deux connexions imposée par la RFC 2616 que les piles HTTP côté client. Cet ensemble d’API est similaire à celui de WinInet, de sorte que ceux qui connaissent WinInet trouvent qu’il est facile de s’adapter.

Une autre solution consiste à utiliser des sockets directement. Le Kit de développement logiciel (SDK) de plateforme inclut un exemple qui montre comment utiliser WinSock sur le protocole SSL. Vous trouverez un exemple dans le \Microsoft Platform SDK\Samples\Winbase\Security\Ssl dossier du Kit de développement logiciel (SDK).

Un autre problème à connaître lors de l’utilisation de WinInet dans un environnement serveur est la limite de deux connexions imposée par internet Explorer.

Bien qu’il soit possible d’utiliser WinInet dans un service et dans un environnement serveur, il n’est pas recommandé ni pris en charge par Microsoft. WinInet n’a pas été testé dans cette configuration et des problèmes existent.