Оцінюйте URL-адреси PAC, які повертає CFNetworkCopyProxiesForURL
Перетворюйте результати автоматичного налаштування проксі CFNetwork на маршрути, специфічні для призначення, не плутаючи адресу PAC з кінцевою точкою проксі.
Ваша програма запитує CFNetwork, як дістатися вебсайту, і отримує URL, що закінчується на .pac. Вставляти це ім'я хоста в socket-з'єднання — хибний шлях: воно вказує на скрипт конфігурації.
CFNetworkCopyProxiesForURL повертає впорядкований масив словників для цільового URL. Перевірте kCFProxyTypeKey, перш ніж читати поля кінцевої точки. Словник типу kCFProxyTypeAutoConfigurationURL надає kCFProxyAutoConfigurationURLKey, що потребує ще одного кроку оцінювання.
- Отримайте поточні системні налаштування проксі та запитайте маршрути до фактичного URL призначення.
- Коли результат посилається на URL PAC, оцініть цей скрипт для того самого призначення.
- Прочитайте типи й кінцеві точки отриманих кандидатів. Проксі HTTP, проксі SOCKS і прямий маршрут потребують різної обробки з'єднання.
- Зберігайте порядок кандидатів, застосовуючи дозволену поведінку відмови та резервування.
CFNetworkExecuteProxyAutoConfigurationURL асинхронно завантажує й оцінює скрипт. Його негайне значення повернення — джерело run loop. Заплануйте це джерело; після завершення роботи зворотний виклик надає результат оцінювання або помилку. Створення джерела й негайне читання порожньої змінної результату нічого не чекає. Анулюйте джерело, якщо операцію треба скасувати.
Тримайте цільовий URL прив'язаним до запиту. Скрипт PAC може вибрати різні маршрути для двох хостів, тому збереження одного розв'язаного проксі як відповіді для кожного наступного призначення змінює політику скрипта. Так само прямий кандидат — це явний маршрут, а не відсутнє ім'я хоста проксі.
Ці API корисні, коли власний транспорт має інтерпретувати системні налаштування. Вони не реалізують наступний протокол проксі для цього транспорту, і запит не отримує паролі з Keychain. У macOS зіставляйте облікові дані проксі в Keychain окремо.