Проксі, наладжаны для аднаго імененнага HttpClient, не наладжвае аўтаматычна кожны кліент, які вяртае IHttpClientFactory. Трымайце імя рэгістрацыі і запытанае імя разам.

services.AddHttpClient("via-proxy")
    .ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
    {
        Proxy = new WebProxy("http://203.0.113.10:8080"),
        UseProxy = true
    });

Затым атрымайце гэтую імененную канфігурацыю:

var client = factory.CreateClient("via-proxy");

Канчатковы пункт прыведзены для ілюстрацыі. Для дазволеных запытаў да публічных сэрвісаў спіс HTTP-проксі дае кандыдатаў для WebProxy URL імененнага кліента. Стварэнне кліента па змаўчанні без імя ў іншым месцы — гэта іншы пошук, нават калі абодва кліенты паходзяць з аднаго ін'ектаванага фабрыкі.

Наладжвайце паводзіны проксі на ўзроўні злучэння ў асноўным апрацоўшчыку, а не разглядайце яго як загаловак запыту прызначэння. Фабрыка можа кіраваць тэрмінамі жыцця апрацоўшчыкаў асобна ад аб'ектаў HttpClient, якія яна вяртае.

Калі выклік належыць тыпізаванаму кліенту або іншаму SDK, праверце, якая рэгістрацыя пастаўляе яго HttpClient. Правільна наладжаны імененны кліент, які ніколі не выкарыстоўваецца, не ўплывае на сеткавы шлях гэтага SDK.

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

Падобныя артыкулы