É seguro un IWebProxy .NET compartido con solicitudes simultáneas?

IWebProxy describe unha política de proxy. Non outorga a todas as implementacións as mesmas garantías de simultaneidade. Antes de compartir unha instancia entre tarefas de traballo, identifique a súa implementación concreta e a contorna de execución á que pertence.

A interface expón consultas de ruta dependentes do destino e credenciais. Unha implementación personalizada pode consultar un enderezo fixo, un estado mutable ou unha configuración automática. Esas escollas afectan tanto á seguridade como ao rendemento.

Manteña os cambios de configuración fóra do procesamento de solicitudes

Evite usar un obxecto proxy compartido como borrador: cambiar o seu enderezo ou as súas credenciais para o traballo A mentres o traballo B selecciona unha ruta fai que a propiedade sexa pouco clara. Configure unha política antes de entregala ao cliente. Para cargas de traballo con contas ou extremos de proxy distintos, use configuracións de cliente con propiedade separada.

A documentación histórica de WebProxy non ofrecía garantía de seguridade de fíos para os membros de instancia. Aplique ese contrato á implementación correspondente. Se se require sincronización, cada lector e escritor deben participar; un bloqueo de envoltura non pode coordinar os chamadores que usan o obxecto orixinal directamente.

Unha pausa longa en GetProxy pode implicar en cambio descubrimento ou avaliación de PAC. Microsoft documenta o descubrimento bloqueante para WinHTTP; esa explicación aplícase cando o cliente usa ese backend. Mida a busca de ruta por separado do tempo de conexión e resposta. Serializar unha busca lenta só pode crear unha cola.

Un extremo fixo pode eliminar o descubrimento cando se pretende unha ruta fixa. Capturar un único URI dunha política de sistema cambiante tamén descartar as súas decisións futuras. Conserve esa distinción ao manter código legado; use HttpClient e a súa configuración de controlador admitida para traballo HTTP novo.