Problèmes autoProxy dans WinHTTP
Tenez compte des problèmes importants suivants lors de l’utilisation de la fonctionnalité autoproxy WinHTTP.
Un seul serveur proxy est actuellement pris en charge
WinHTTP ne prend actuellement pas en charge les configurations de proxy qui spécifient plusieurs serveurs proxy. Si WinHttpGetProxyForUrl retourne une structure WINHTTP_PROXY_INFO qui contient une liste de serveurs proxy, que l’application définit ensuite sur le handle de requête à l’aide de l’option WINHTTP_OPTION_PROXY, WinHTTP utilise uniquement le premier serveur proxy de la liste. Si ce serveur proxy n’est pas accessible, WinHTTP ne bascule vers aucun des autres serveurs proxy de la liste. Il incombe à l’application de gérer ce cas en définissant à nouveau l’option WINHTTP_OPTION_PROXY avec le serveur proxy suivant dans la liste et en renvoyant la requête.
Atténuation des risques de sécurité
Le traitement du fichier de configuration automatique du proxy nécessite l’exécution du code de script téléchargé. Certaines préoccupations de sécurité à prendre en compte : si le serveur sur lequel réside le fichier PAC a été compromis, il est possible que le code de script PAC soit malveillant. Par conséquent, WinHTTP utilise les précautions suivantes pour protéger le client :
Le code de script n’est pas empêché d’instancier des objets ActiveX. Cela bloque beaucoup de fonctionnalités potentiellement dangereuses, telles que la possibilité d’accéder aux fichiers et d’effectuer des E/S réseau.
**Windows Server 2003 : **WinHttpGetProxyForUrl délègue l’ensemble du traitement WPAD à un service externe hors processus, le service de découverte automatique du proxy web WinHTTP, qui s’exécute sous le compte d’utilisateur intégré du service local à faible privilège.
Windows XP avec SP2 et Windows Server 2003 : un script PAC n’est pas autorisé à s’exécuter pendant plus de 60 secondes, après quoi l’exécution du script est terminée.
Windows XP avec SP2 et Windows Server 2003 : WinHTTP rejette les fichiers PAC supérieurs à 1 Mo. Un fichier PAC classique n’est généralement pas plus de quelques kilo-octets de taille.
N’oubliez pas que le traitement du code de script PAC nécessite l’utilisation de COM, car WinHTTP utilise le composant Microsoft JScript pour exécuter le script. Si WinHTTP ne peut pas déléguer le traitement du protocole WPAD à un service de découverte automatique de proxy web externe hors processus, WinHttpGetProxyForUrl charge le runtime COM dans le processus d’application pendant la durée de l’appel. Si l’application elle-même utilise déjà COM, cela ne doit pas être un problème.
Considérations relatives aux performances
Le processus de détection automatique peut être lent, éventuellement pendant plusieurs secondes. Les fonctions WinHttpGetProxyForUrl et WinHttpDetectAutoProxyConfigUrl bloquent les fonctions synchrones. Il peut s’agir d’un mécanisme particulier de détection automatique (tel que DHCP) est beaucoup plus lent que l’autre (tel que DNS). Si les indicateurs de détection automatique WINHTTP_AUTO_DETECT_TYPE_DHCP et WINHTTP_AUTO_DETECT_TYPE_DNS_A sont spécifiés, WinHTTP utilise d’abord DHCP, conformément à la spécification WPAD. Si aucune URL PAC n’est détectée en émettant une requête DHCP, WinHTTP tente de localiser le fichier PAC à une adresse DNS connue.
WinHttpGetProxyForUrl utilise le paramètre de handle de session WinHTTP pour mettre en cache le fichier PAC et les résultats de la détection automatique. Il est préférable d’utiliser le même handle de session pour plusieurs appels WinHttpGetProxyForUrl si possible pour éviter la détection d’URL PAC répétée et le téléchargement de fichiers. Le fichier PAC est mis en cache en mémoire uniquement et est ignoré lorsque l’application ferme le handle de session.
En raison de l’impact sur les performances de l’autoproxy, il est recommandé que seules les applications clientes de bureau ou les services utilisent la fonctionnalité ; Les applications basées sur le serveur doivent s’appuyer sur l’administrateur du serveur à l’aide de l’utilitaire «ProxyCfg.exe».