Безопасен ли споделен .NET IWebProxy при едновременни заявки?

IWebProxy описва прокси политика. Той не дава на всяка реализация едни и същи гаранции за паралелност. Преди да споделите един екземпляр между работни задачи, идентифицирайте конкретната му реализация и средата за изпълнение, към която принадлежи.

Интерфейсът предоставя зависими от дестинацията заявки за маршрут и идентификационни данни. Персонализирана реализация може да се обръща към фиксиран адрес, променливо състояние или автоматична конфигурация. Тези избори влияят както на сигурността, така и на производителността.

Дръжте промените в конфигурацията извън обработката на заявки

Избягвайте да използвате един споделен прокси обект като чернова: промяната на адреса или идентификационните данни за задача A, докато задача B избира маршрут, прави собствеността неясна. Конфигурирайте политиката, преди да я предадете на клиента. За натоварвания с различни прокси акаунти или крайни точки използвайте отделно притежавани клиентски конфигурации.

Историческата документация на WebProxy не даваше гаранция за безопасност на нишките за членове на екземпляра. Приложете този договор към съответната реализация. Ако е необходима синхронизация, всеки читател и писател трябва да участва; заключване-обвивка не може да координира извикващи, които използват оригиналния обект директно.

Дълга пауза в GetProxy може вместо това да включва откриване или оценка на PAC. Microsoft документира блокиращо откриване за WinHTTP; това обяснение се прилага, когато клиентът използва този бекенд. Измерете търсенето на маршрут отделно от времето за свързване и отговор. Сериализирането на бавно търсене може само да създаде опашка.

Фиксирана крайна точка може да премахне откриването, когато е предвиден фиксиран маршрут. Заснемането на един URI от променяща се системна политика също отхвърля бъдещите ѝ решения. Запазете това разграничение при поддръжка на стар код; използвайте HttpClient и поддържаната му конфигурация на манипулатор за нови HTTP задачи.