.NET IWebProxy: unikaj rzutowania proxy systemowych na WebProxy
Obsługuj proxy systemowe zwrócone jako IWebProxy, nie zakładając, że jego konkretna klasa to WebProxy.
IWebProxy policy = WebRequest.GetSystemWebProxy();
request.Proxy = policy;
Zachowaj zwrócony obiekt jako IWebProxy. Ten fragment dotyczy istniejącego kodu opartego na WebRequest, a nie jest zaleceniem przyjęcia tego przestarzałego API w nowej aplikacji.
WebProxy implementuje interfejs, ale nie każdy obiekt implementujący interfejs dziedziczy z WebProxy. Otoczka systemowa może więc odrzucić rzutowanie, zanim dojdzie do jakiegokolwiek żądania sieciowego. Prywatna nazwa klasy .NET Framework, taka jak WebProxyWrapperOpaque, to szczegół implementacji, a nie problem punktu końcowego proxy czy konta.
Aby podjąć decyzję o trasie, wywołaj IsBypassed(destination) i GetProxy(destination) z rzeczywistym URI miejsca docelowego. Pominięcie może zwrócić samo miejsce docelowe, a zasada oparta na PAC może wybrać inną trasę dla innego hosta.
W przypadku uwierzytelniania IWebProxy już udostępnia Credentials. Użyj obsługiwanego konta i metody bez rzutowania, aby uzyskać dostęp do właściwości.
Wyodrębnienie jednego URI w celu zbudowania zastępczego WebProxy odrzuca zachowanie oryginalnej zasady dla poszczególnych miejsc docelowych. Rób to tylko wtedy, gdy stały punkt końcowy jest zamierzoną konfiguracją aplikacji, a nie obejściem błędu typu.