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 pas actuellement en charge les configurations de proxy qui spécifient plusieurs serveurs proxy. Si WinHttpGetProxyForUrl retourne une structure de WINHTTP_PROXY_INFO qui contient une liste de serveurs proxy, que l’application définit ensuite sur le handle de demande à 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 appartient à l’application de gérer ce cas en définissant à nouveau l’option WINHTTP_OPTION_PROXY avec le serveur proxy suivant dans la liste, puis en renvoyant la demande.

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é. Quelques problèmes 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 du script PAC soit malveillant. Par conséquent, WinHTTP utilise les précautions suivantes pour protéger le client :

1. Le code de script ne peut pas instancier des objets ActiveX. Cela bloque de nombreuses fonctionnalités potentiellement dangereuses, telles que la possibilité d’accéder aux fichiers et d’effectuer des E/S réseau.

2. **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èges.

3. 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.

4. Windows XP avec SP2 et Windows Server 2003 : WinHTTP rejette les fichiers PAC de plus de 1 Mo. Un fichier PAC classique n’a généralement pas plus de quelques kilo-octets.

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 externe de découverte automatique de proxy web hors processus, WinHttpGetProxyForUrl charge le runtime COM au sein du 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, peut-être de plusieurs secondes. Les fonctions WinHttpGetProxyForUrl et WinHttpDetectAutoProxyConfigUrl sont des fonctions synchrones bloquantes. Il se peut qu’un mécanisme de détection automatique particulier (tel que DHCP) soit beaucoup plus lent que l’autre (comme 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écouverte par l’émission d’une requête DHCP, WinHTTP tente de localiser le fichier PAC à une adresse DNS connue.

WinHttpGetProxyForUrl utilise le paramètre de handle 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 afin d’éviter la détection répétée de l’URL PAC et le téléchargement de fichiers. Le fichier PAC est mis en cache uniquement en mémoire 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 seuls les services ou applications clientes de bureau utilisent la fonctionnalité ; les applications basées sur serveur doivent s’appuyer sur l’administrateur de serveur à l’aide de l’utilitaire « ProxyCfg.exe ».