A është i sigurt një IWebProxy .NET i përbashkët në kërkesat e njëkohshme?

IWebProxy përshkruan një politikë përfaqësuesi. Ai nuk i jep çdo implementimi të njëjtat garanci njëkohshmërie. Përpara se të ndani një instancë midis detyrave të punëtorëve, identifikoni implementimin e saj konkret dhe mjedisin e ekzekutimit ku bën pjesë.

Ndërfaqja ekspozon pyetje rrugësh që varen nga destinacioni dhe kredenciale. Një implementim i personalizuar mund të konsultojë një adresë fikse, gjendje të ndryshueshme ose konfigurim automatik. Këto zgjedhje ndikojnë si në siguri ashtu edhe në performancë.

Mbajini ndryshimet e konfigurimit jashtë përpunimit të kërkesave

Shmangni përdorimin e një objekti të përbashkët përfaqësuesi si draft: ndryshimi i adresës ose kredencialeve të tij për punën A ndërsa puna B zgjedh një rrugë e bën pronësinë të paqartë. Konfiguroni një politikë përpara se t'ia dorëzoni klientit. Për ngarkesa pune me llogari ose pika fundore përfaqësuesi të ndryshme, përdorni konfigurime klienti të zotëruara veçmas.

Dokumentacioni historik i WebProxy nuk jepte garanci sigurie fijesh për anëtarët e instancës. Zbatojeni atë kontratë në implementimin përkatës. Nëse kërkohet sinkronizim, çdo lexues dhe shkrues duhet të marrë pjesë; një bravë mbështjellëse nuk mund të koordinojë thirrësit që përdorin drejtpërdrejt objektin origjinal.

Një pauzë e gjatë në GetProxy mund të përfshijë në vend të kësaj zbulim ose vlerësim PAC. Microsoft dokumenton zbulimin bllokues për WinHTTP; ai shpjegim zbatohet kur klienti përdor atë backend. Matni kërkimin e rrugës veçmas nga koha e lidhjes dhe përgjigjes. Serializimi i një kërkimi të ngadaltë mund të krijojë vetëm një radhë.

Një pikë fundore fikse mund të heqë zbulimin kur synohet një rrugë fikse. Kapja e një URI të vetme nga një politikë sistemi në ndryshim gjithashtu hedh poshtë vendimet e saj të ardhshme. Ruajeni atë dallim kur mirëmbani kod të vjetër; përdorni HttpClient dhe konfigurimin e tij të mbështetur të trajtuesit për punë të re HTTP.