Ձեր հավելվածը 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-ում։

Առնչվող հոդվածներ