Manteniu un gestor .NET separat per a cada compte de proxy
Creeu gestors separats per als comptes simultanis en lloc de substituir WebProxy.Credentials en un transport que ja serveix peticions.
Un transport pot retenir l’objecte proveïdor de credencials de proxy triat quan es va crear el seu gestor de pool. Substituir WebProxy.Credentials després no és una operació fiable de canvi de compte.
Creeu la ruta i el compte junts abans d’utilitzar el client:
var proxy = new System.Net.WebProxy(proxyEndpoint)
{
Credentials = new System.Net.NetworkCredential(proxyUser, proxyPassword)
};
var handler = new System.Net.Http.HttpClientHandler
{
UseProxy = true,
Proxy = proxy
};
var client = new System.Net.Http.HttpClient(handler);El punt final i les credencials provenen de la configuració de l’aplicació. Creeu un altre gestor per a una segona identitat; un altre HttpClient que comparteixi el primer gestor també comparteix la seva política.
Un proveïdor ICredentials personalitzat pot respondre a desafiaments posteriors, però no pot reetiquetar un túnel establert com un altre compte. Assignar un únic usuari/contrasenya global al voltant de crides asíncrones deixa el moment del desafiament i la propietat del compte en conflicte.
Manteniu un conjunt limitat de clients quan calgui reutilitzar. Buideu la feina antiga abans d’eliminar el seu transport. Un gestor nou per petició malbarata els pools de connexions; mantenir tots els comptes històrics per sempre els fa créixer sense límit.