Tenu apartan .NET-traktilon por ĉiu proxy-konto
Konstruu apartajn traktilojn por samtempaj kontoj anstataŭ anstataŭigi WebProxy.Credentials sur transporto jam servanta petojn.
Transporto povas reteni la proxy-akreditilprovizanton objekton elektitan kiam ĝia naĝejadministranto estis kreita. Anstataŭigi WebProxy.Credentials poste ne estas fidinda kontoŝanĝo.
Kreu la itineron kaj la konton kune antaŭ ol uzi la klienton:
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);La finpunkto kaj la akreditiloj venas de la aplikaĵa agordo. Konstruu alian traktilon por dua identeco; alia HttpClient kiu dividas la unuan traktilon ankaŭ dividas ĝian politikon.
Propra ICredentials-provizanto povas respondi al pli postaj defioj, sed ĝi ne povas renomi establitan tunelon kiel alian konton. Asigni unu tutmondan uzantnomon/pasvorton ĉirkaŭ nesinkronaj alvokoj estas lasi defian tempon kaj kontan posedrajton en konflikto.
Tenu limigitan aron da klientoj kiam reuzo necesas. Elfluigu malnovan laboron antaŭ ol forigi ĝian transporton. Nova traktilo por ĉiu peto malŝparas konektajn naĝejojn; teni ĉiun historian konton por ĉiam kreskigas ilin sen limo.