CFNetworkCopyProxiesForURL-ის მიერ დაბრუნებული PAC URL-ების შეფასება

თქვენი აპლიკაცია CFNetwork-ს ეკითხება, როგორ მიაღწიოს ვებსაიტს, და იღებს URL-ს, რომელიც .pac-ით მთავრდება. ამ ჰოსტის სახელის socket-ის კავშირში ჩასმა არასწორი გზაა: ის კონფიგურაციის სკრიპტს განსაზღვრავს.

CFNetworkCopyProxiesForURL სამიზნე URL-ისთვის აბრუნებს ლექსიკონების დალაგებულ მასივს. სანამ საბოლოო წერტილის ველებს წაიკითხავთ, შეამოწმეთ kCFProxyTypeKey. kCFProxyTypeAutoConfigurationURL ტიპის ლექსიკონი იძლევა kCFProxyAutoConfigurationURLKey-ს, რომელიც კიდევ ერთ შეფასების საფეხურს მოითხოვს.

1. მიიღეთ სისტემის მიმდინარე პროქსის პარამეტრები და მოითხოვეთ მარშრუტები რეალურ სამიზნე URL-მდე.
2. როცა შედეგი PAC URL-ს მიუთითებს, შეაფასეთ ის სკრიპტი იმავე დანიშნულებისთვის.
3. წაიკითხეთ მიღებული კანდიდატების ტიპები და საბოლოო წერტილები. HTTP პროქსი, SOCKS პროქსი და პირდაპირი მარშრუტი კავშირის განსხვავებულ დამუშავებას მოითხოვს.
4. დაშვებული წარუმატებლობისა და სარეზერვო ქცევის გამოყენებისას შეინარჩუნეთ კანდიდატების რიგი.

CFNetworkExecuteProxyAutoConfigurationURL სკრიპტს ასინქრონულად ტვირთავს და აფასებს. მისი მყისიერი დაბრუნების მნიშვნელობა run loop-ის წყაროა. დაგეგმეთ ეს წყარო; სამუშაოს დასრულების შემდეგ callback აბრუნებს შეფასების შედეგს ან შეცდომას. წყაროს შექმნა და ცარიელი შედეგის ცვლადის დაუყოვნებლივ წაკითხვა არაფერს ელოდება. გააუქმეთ წყარო, თუ ოპერაცია უნდა გაუქმდეს.

შეინახეთ სამიზნე URL მოთხოვნასთან მიბმული. PAC სკრიპტმა შეიძლება ორი ჰოსტისთვის სხვადასხვა მარშრუტი აირჩიოს, ამიტომ ერთი ამოხსნილი პროქსის შენახვა, როგორც პასუხი ყველა მომდევნო დანიშნულებაზე, ცვლის სკრიპტის პოლიტიკას. ანალოგიურად, პირდაპირი კანდიდატი ცხადი მარშრუტია და არა დაკარგული პროქსის ჰოსტის სახელი.

ეს API-ები სასარგებლოა, როცა მორგებულ ტრანსპორტს სისტემის პარამეტრების ინტერპრეტაცია სჭირდება. ისინი არ ახორციელებენ ამ ტრანსპორტის შემდგომ პროქსის პროტოკოლს და მოთხოვნა Keychain-იდან პაროლებს არ იღებს. macOS-ზე ცალკე შეადარეთ პროქსის სამოწმებელი Keychain-ში.