Да ли је дељени .NET IWebProxy безбедан код истовремених захтева?

IWebProxy описује прокси политику. Не даје свакој имплементацији исте гаранције истовремености. Пре него што поделите једну инстанцу између радних задатака, идентификујте њену конкретну имплементацију и окружење којем припада.

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

Држите промене конфигурације изван обраде захтева

Избегавајте коришћење једног дељеног прокси објекта као радне скице: промена његове адресе или акредитива за задатак A док задатак B бира руту чини власништво нејасним. Конфигуришите политику пре него што је предате клијенту. За оптерећења са различитим прокси налозима или крајњим тачкама користите одвојено поседоване конфигурације клијента.

Историјска документација WebProxy-а није давала гаранцију безбедности нити за чланове инстанце. Примените тај уговор на одговарајућу имплементацију. Ако је потребна синхронизација, сваки читач и писац морају учествовати; закључавање омотача не може координисати позиваоце који директно користе оригинални објекат.

Дуга пауза у GetProxy може уместо тога укључивати откривање или процену PAC-а. Microsoft документује блокирајуће откривање за WinHTTP; то објашњење важи када клијент користи тај позадински систем. Мерите тражење руте одвојено од времена везе и одговора. Серијализација спорог тражења може само да створи ред.

Фиксна крајња тачка може уклонити откривање када је предвиђена фиксна рута. Снимање једног URI-ја из промењиве системске политике такође одбацује његове будуће одлуке. Сачувајте ту разлику при одржавању старог кода; користите HttpClient и његову подржану конфигурацију руковаоца за нови HTTP посао.