Je li dijeljeni .NET IWebProxy siguran kod istovremenih zahtjeva?
Razlikujte ugovor o istovremenosti implementacije IWebProxy od kašnjenja uzrokovanih automatskim otkrivanjem proxyja.
IWebProxy opisuje proxy politiku. On ne daje svakoj implementaciji iste garancije istovremenosti. Prije nego što podijelite jednu instancu između radnih zadataka, identificirajte njenu konkretnu implementaciju i okruženje kojem pripada.
Interfejs izlaže upite rute zavisne od odredišta i akreditive. Prilagođena implementacija može konsultovati fiksnu adresu, promjenjivo stanje ili automatsku konfiguraciju. Ti izbori utič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 akreditiva 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.
Historijska dokumentacija WebProxyja nije davala garanciju sigurnosti niti za članove instance. Primijenite taj ugovor na odgovarajuću implementaciju. Ako je potrebna sinhronizacija, svaki čitalac i pisac mora učestvovati; brava omotača ne može koordinirati pozivaoce koji direktno koriste originalni objekt.
Duga pauza u GetProxy može umjesto toga uključivati otkrivanje ili procjenu PAC-a. Microsoft dokumentuje blokirajuće otkrivanje za WinHTTP; to objašnjenje vrijedi kada klijent koristi taj pozadinski sistem. 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 rukovaoca za nove HTTP poslove.