Je li dijeljeni .NET IWebProxy siguran kod istovremenih zahtjeva?
Razlikujte ugovor istovremenosti implementacije IWebProxy od kašnjenja uzrokovanih automatskim otkrivanjem proxyja.
IWebProxy opisuje proxy politiku. Ne daje svakoj implementaciji iste garancije istovremenosti. Prije nego što podijelite jednu instancu između radnih zadataka, identificirajte njezinu konkretnu implementaciju i okruženje kojem pripada.
Sučelje izlaže upite rute koji ovise o odredištu i vjerodajnice. Prilagođena implementacija može konzultirati fiksnu adresu, promjenjivo stanje ili automatsku konfiguraciju. Ti izbori utječu i na sigurnost i na performanse.
Držite promjene konfiguracije izvan obrade zahtjeva
Izbjegavajte korištenje jednog dijeljenog proxy objekta kao radne skice: promjena njegove adrese ili vjerodajnica za zadatak A dok zadatak B bira rutu čini vlasništvo nejasnim. Konfigurirajte politiku prije nego što je predate klijentu. Za radna opterećenja s različitim proxy računima ili krajnjim točkama koristite odvojeno posjedovane konfiguracije klijenata.
Povijesna dokumentacija WebProxyja nije davala jamstvo sigurnosti niti za članove instance. Primijenite taj ugovor na odgovarajuću implementaciju. Ako je potrebna sinkronizacija, svaki čitatelj i pisac moraju sudjelovati; brava omotača ne može koordinirati pozivatelje koji izravno koriste izvorni objekt.
Duga stanka u GetProxy može umjesto toga uključivati otkrivanje ili procjenu PAC-a. Microsoft dokumentira blokirajuće otkrivanje za WinHTTP; to objašnjenje vrijedi kada klijent koristi taj pozadinski sustav. Mjerite traženje rute odvojeno od vremena veze i odgovora. Serijalizacija sporog traženja može samo stvoriti red.
Fiksna krajnja točka može ukloniti otkrivanje kada je predviđena fiksna ruta. Snimanje jednog URI-ja iz promjenjive sistemske politike također odbacuje njegove buduće odluke. Sačuvajte tu razliku pri održavanju naslijeđenog koda; koristite HttpClient i njegovu podržanu konfiguraciju rukovatelja za nove HTTP poslove.