Трымайце асобны .NET-апрацоўшчык для кожнага проксі-акаўнта

Транспарт можа захоўваць аб’ект пастаўшчыка ўліковых даных проксі, выбраны пры стварэнні яго менеджара пула. Замена WebProxy.Credentials пасля гэтага не з’яўляецца надзейнай аперацыяй пераключэння акаўнта.

Стварыце маршрут і акаўнт разам, перш чым выкарыстоўваць кліент:

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

Канчатковы пункт і ўліковыя даныя бяруцца з канфігурацыі праграмы. Для другой асобы пабудуйце іншы апрацоўшчык; іншы HttpClient, які дзеліць першы апрацоўшчык, дзеліць і яго палітыку.

Уласны пастаўшчык ICredentials можа адказваць на познія выклікі, але ён не можа перайменаваць усталяваны тунель у іншы акаўнт. Прызначэнне адзінага глабальнага імя карыстальніка/пароля вакол асінхронных выклікаў пакідае час выкліку і ўласнасць акаўнта ў канфлікце.

Трымайце абмежаваны набор кліентаў, калі патрэбна паўторнае выкарыстанне. Зліце старую працу перад вызваленнем яе транспарту. Новы апрацоўшчык на кожны запыт марнуе пулы злучэнняў; захоўванне ўсіх гістарычных акаўнтаў назаўжды расціць іх без мяжы.