És segur un IWebProxy .NET compartit amb sol·licituds simultànies?

IWebProxy descriu una política de proxy. No atorga a cada implementació les mateixes garanties de simultaneïtat. Abans de compartir una instància entre tasques de treball, identifiqueu-ne la implementació concreta i l'entorn d'execució al qual pertany.

La interfície exposa consultes de ruta dependents de la destinació i credencials. Una implementació personalitzada pot consultar una adreça fixa, estat mutable o configuració automàtica. Aquestes eleccions afecten tant la seguretat com el rendiment.

Mantingueu els canvis de configuració fora del processament de sol·licituds

Eviteu fer servir un objecte proxy compartit com a esborrany: canviar-ne l'adreça o les credencials per a la feina A mentre la feina B selecciona una ruta fa que la propietat sigui poc clara. Configureu una política abans de lliurar-la al client. Per a càrregues amb comptes o punts finals de proxy diferents, useu configuracions de client amb propietat separada.

La documentació històrica de WebProxy no oferia cap garantia de seguretat de fils per als membres d'instància. Apliqueu aquest contracte a la implementació corresponent. Si cal sincronització, cada lector i escriptor hi ha de participar; un bloqueig d'embolcall no pot coordinar els cridaners que fan servir l'objecte original directament.

Una pausa llarga a GetProxy pot implicar en canvi el descobriment o l'avaluació de PAC. Microsoft documenta el descobriment bloquejant per a WinHTTP; aquesta explicació s'aplica quan el client fa servir aquest backend. Mesureu la cerca de ruta per separat del temps de connexió i resposta. Serialitzar una cerca lenta només pot crear una cua.

Un punt final fix pot eliminar el descobriment quan es pretén una ruta fixa. Capturar un sol URI d'una política de sistema canviant també descarta les seves decisions futures. Conserveu aquesta distinció en mantenir codi antic; useu HttpClient i la seva configuració de controlador admesa per a feina HTTP nova.