Mantieni un gestore .NET separato per ogni account proxy

Un trasporto può conservare l’oggetto provider di credenziali proxy scelto quando è stato creato il suo gestore del pool. Sostituire WebProxy.Credentials in seguito non è un’operazione affidabile di cambio account.

Crea la route e l’account insieme prima di usare il 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);

L’endpoint e le credenziali provengono dalla configurazione dell’applicazione. Crea un altro gestore per una seconda identità; un altro HttpClient che condivide il primo gestore condivide anche la sua politica.

Un provider ICredentials personalizzato può rispondere a sfide successive, ma non può rietichettare un tunnel stabilito come un altro account. Assegnare un unico nome utente/password globale attorno a chiamate asincrone lascia il momento della sfida e la proprietà dell’account in conflitto.

Mantieni un insieme limitato di client quando è necessario il riutilizzo. Svuota il lavoro vecchio prima di eliminare il suo trasporto. Un nuovo gestore per richiesta spreca i pool di connessioni; conservare ogni account storico per sempre li fa crescere senza limite.