Für jedes Proxy-Konto einen eigenen .NET-Handler behalten

Ein Transport kann das Proxy-Anmeldeinformations-Provider-Objekt behalten, das beim Erstellen seines Pool-Managers gewählt wurde. WebProxy.Credentials danach zu ersetzen ist kein verlässlicher Kontowechsel.

Erstellen Sie Route und Konto gemeinsam, bevor Sie den Client verwenden:

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);

Endpunkt und Anmeldeinformationen stammen aus der Anwendungskonfiguration. Erstellen Sie einen weiteren Handler für eine zweite Identität; ein weiterer HttpClient, der den ersten Handler teilt, teilt auch dessen Richtlinie.

Ein benutzerdefinierter ICredentials-Provider kann spätere Aufforderungen beantworten, aber er kann einen bestehenden Tunnel nicht als anderes Konto umetikettieren. Ein globaler Benutzername/ein globales Kennwort um asynchrone Aufrufe herum lässt Aufforderungszeitpunkt und Kontozugehörigkeit in Konflikt geraten.

Halten Sie eine begrenzte Anzahl von Clients, wenn Wiederverwendung nötig ist. Leeren Sie alte Arbeit, bevor Sie den Transport freigeben. Ein neuer Handler pro Anforderung verschwendet Verbindungspools; alle historischen Konten ewig zu behalten lässt sie unbegrenzt wachsen.