.NET IWebProxy: пазбягайце прывядзення сістэмных проксі да WebProxy
Апрацоўвайце сістэмны проксі, вернуты як IWebProxy, не мяркуючы, што яго канкрэтны клас — WebProxy.
IWebProxy policy = WebRequest.GetSystemWebProxy();
request.Proxy = policy;Пакідайце вернуты аб'ект як IWebProxy. Гэты фрагмент датычыцца існуючага кода на аснове WebRequest, а не рэкамендацыі выкарыстоўваць гэты састарэлы API ў новым праграмным забеспячэнні.
WebProxy рэалізуе інтэрфейс, але не кожны аб'ект, які рэалізуе інтэрфейс, наследуе ад WebProxy. Таму сістэмная абгортка можа адхіліць прывядзенне да любога сеткавага запыту. Прыватная назва класа .NET Framework, напрыклад WebProxyWrapperOpaque, — гэта дэталь рэалізацыі, а не праблема канчатковага пункта проксі ці ўліковага запісу.
Для рашэння аб маршруце выклікайце IsBypassed(destination) і GetProxy(destination) з фактычным URI прызначэння. Абыход можа вярнуць само гэтае прызначэнне, а палітыка на аснове PAC можа выбраць іншы маршрут для іншага хоста.
Для аўтэнтыфікацыі IWebProxy ужо прадастаўляе Credentials. Выкарыстоўвайце падтрымліваемы ўліковы запіс і метад без прывядзення, каб атрымаць доступ да ўласцівасці.
Выманне аднаго URI для пабудовы заменнага WebProxy адкідае паводзіны зыходнай палітыкі для кожнага прызначэння. Рабіце гэта, толькі калі фіксаваны канчатковы пункт — мэтавая канфігурацыя праграмы, а не як абыход памылкі тыпу.