Problemy z autoproxy w usłudze WinHTTP
Podczas korzystania z funkcji autoproxy WinHTTP należy wziąć pod uwagę następujące ważne problemy.
Obecnie obsługiwany jest tylko jeden serwer proxy
WinHTTP nie obsługuje obecnie konfiguracji serwera proxy, które określają więcej niż jeden serwer proxy. Jeśli WinHttpGetProxyForUrl zwraca strukturę WINHTTP_PROXY_INFO zawierającą listę serwerów proxy, które następnie aplikacja ustawia na dojściu żądania przy użyciu opcji WINHTTP_OPTION_PROXY, winHTTP używa tylko pierwszego serwera proxy na liście. Jeśli ten serwer proxy nie jest dostępny, usługa WinHTTP nie zostanie przełączona w tryb failover do żadnego z innych serwerów proxy na liście. Aplikacja musi obsługiwać ten przypadek, ustawiając ponownie opcję WINHTTP_OPTION_PROXY z następnym serwerem proxy na liście i ponownie wysyłając żądanie.
Ograniczenie ryzyka zabezpieczeń
Przetwarzanie pliku automatycznej konfiguracji serwera proxy wymaga wykonania pobranego kodu skryptu. Należy wziąć pod uwagę pewne obawy dotyczące zabezpieczeń: jeśli serwer, na którym znajduje się plik PAC, został naruszony, istnieje możliwość, że kod skryptu PAC jest złośliwy. W związku z tym usługa WinHTTP używa następujących środków ostrożności w celu ochrony klienta:
Kod skryptu nie może utworzyć wystąpienia żadnych obiektów ActiveX. Blokuje to wiele potencjalnie niebezpiecznych funkcji, takich jak możliwość uzyskiwania dostępu do plików i wykonywania operacji we/wy sieci.
**Windows Server 2003: **WinHttpGetProxyForUrl deleguje całe przetwarzanie WPAD do zewnętrznej usługi poza procesem, usługi automatycznego odnajdywania serwera proxy sieci Web WinHTTP, która działa w ramach wbudowanego konta użytkownika usługi lokalnej o niskich uprawnieniach.
windows XP z dodatkiem SP2 i Windows Server 2003: skrypt PAC nie może być wykonywany dłużej niż 60 sekund, po którym wykonywanie skryptu zostanie zakończone.
windows XP z dodatkiem SP2 i Windows Server 2003: WinHTTP odrzuca pliki PAC większe niż 1 MB. Typowy plik PAC jest zwykle nie więcej niż kilka kilobajtów rozmiaru.
Należy pamiętać, że przetwarzanie kodu skryptu PAC wymaga użycia modelu COM, ponieważ usługa WinHTTP używa składnika Microsoft JScript do wykonania skryptu. Jeśli winHTTP nie może delegować przetwarzania protokołu WPAD do zewnętrznej, pozaprocesowej usługi automatycznego odnajdywania serwera proxy sieci Web, WinHttpGetProxyForUrl ładuje środowisko uruchomieniowe COM w procesie aplikacji przez czas trwania wywołania. Jeśli sama aplikacja korzysta już z modelu COM, nie powinno to być problemem.
Zagadnienia dotyczące wydajności
Proces automatycznego wykrywania może być powolny, prawdopodobnie nawet kilka sekund. Funkcje WinHttpGetProxyForUrl i WinHttpDetectAutoProxyConfigUrl są blokowane, synchroniczne funkcje. Może się okazać, że jeden konkretny mechanizm automatycznego wykrywania (np. DHCP) jest znacznie wolniejszy niż drugi (np. DNS). Jeśli określono flagi automatycznego wykrywania WINHTTP_AUTO_DETECT_TYPE_DHCP i WINHTTP_AUTO_DETECT_TYPE_DNS_A, winHTTP najpierw używa protokołu DHCP zgodnie ze specyfikacją WPAD. Jeśli żaden adres URL PAC nie zostanie odnaleziony przez wysłanie żądania DHCP, usługa WinHTTP spróbuje zlokalizować plik PAC pod dobrze znanym adresem DNS.
WinHttpGetProxyForUrl używa parametru obsługi sesji WinHTTP do buforowania pliku PAC i wyników automatycznego wykrywania. Najlepiej użyć tego samego dojścia sesji dla wielu WinHttpGetProxyForUrl wywołań, jeśli to możliwe, aby uniknąć wielokrotnego wykrywania adresów URL PAC i pobierania plików. Plik PAC jest buforowany tylko w pamięci i jest odrzucany, gdy aplikacja zamyka dojście sesji.
Ze względu na wpływ autoproxy na wydajność zaleca się, aby tylko aplikacje klienckie lub usługi klasyczne korzystały z tej funkcji; Aplikacje oparte na serwerze powinny polegać na administratorze serwera przy użyciu narzędzia "ProxyCfg.exe".