Gardez un gestionnaire .NET distinct pour chaque compte proxy

Un transport peut conserver l’objet fournisseur d’informations d’identification proxy choisi lors de la création de son gestionnaire de pool. Remplacer WebProxy.Credentials ensuite n’est pas une opération fiable de changement de compte.

Créez la route et le compte ensemble avant d’utiliser le 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);

Le point de terminaison et les informations d’identification proviennent de la configuration de l’application. Créez un autre gestionnaire pour une seconde identité ; un autre HttpClient qui partage le premier gestionnaire partage aussi sa stratégie.

Un fournisseur ICredentials personnalisé peut répondre aux défis ultérieurs, mais il ne peut pas réétiqueter un tunnel établi comme un autre compte. Affecter un seul nom d’utilisateur/mot de passe global autour d’appels asynchrones laisse le moment du défi et la propriété du compte en conflit.

Gardez un ensemble borné de clients lorsque la réutilisation est nécessaire. Videz l’ancien travail avant de libérer son transport. Un nouveau gestionnaire par requête gaspille les pools de connexions ; conserver tous les comptes historiques pour toujours les fait croître sans limite.