.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 відкидає поведінку початкової політики для кожного призначення. Робіть так лише тоді, коли фіксована кінцева точка — це запланована конфігурація застосунку, а не обхід помилки типу.