ერთი დასახელებული 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-ისთვის. ნაგულისხმევი უსახელო კლიენტის სხვაგან შექმნა სხვა ძიებაა, თუნდაც ორივე კლიენტი ერთი და იმავე ინექციური ქარხნიდან მოდიოდეს.

კონფიგურირეთ პროქსის ქცევა კავშირის დონეზე ძირითად handler-ზე, ნაცვლად იმისა, რომ ის დანიშნულების მოთხოვნის header-ად მოიხსენიოთ. ქარხანას შეუძლია handler-ების სიცოცხლის ხანგრძლივობა ცალკე მართოს იმ HttpClient ობიექტებისგან, რომლებსაც აბრუნებს.

თუ გამოძახება ტიპიზებულ კლიენტს ან სხვა SDK-ს ეკუთვნის, შეამოწმეთ რომელი რეგისტრაცია აწვდის მის HttpClient-ს. სწორად კონფიგურირებული დასახელებული კლიენტი, რომელიც არასოდეს გამოიყენება, გავლენას არ ახდენს ამ SDK-ის ქსელურ გზაზე.

გამოიყენეთ ეს კონფიგურაცია სტაბილური მარშრუტიზაციის პოლიტიკისთვის. ცოცხალი handler-ის შეცვლა ოპერაციებს შორის რჩება ცალკე პარალელიზმისა და სიცოცხლის ხანგრძლივობის პრობლემად.

დაკავშირებული სტატიები