Оценка URL-адресов PAC, возвращаемых CFNetworkCopyProxiesForURL

Ваше приложение спрашивает у CFNetwork, как добраться до веб-сайта, и получает URL, заканчивающийся на .pac. Подставлять это имя хоста в соединение socket — неверный путь: оно указывает на скрипт конфигурации.

CFNetworkCopyProxiesForURL возвращает упорядоченный массив словарей для целевого URL. Проверьте kCFProxyTypeKey, прежде чем читать поля конечной точки. Словарь типа kCFProxyTypeAutoConfigurationURL предоставляет kCFProxyAutoConfigurationURLKey, что требует ещё одного шага оценки.

1. Получите текущие системные настройки прокси и запросите маршруты к фактическому URL назначения.
2. Когда результат ссылается на URL PAC, оцените этот скрипт для того же назначения.
3. Прочитайте типы и конечные точки полученных кандидатов. Прокси HTTP, прокси SOCKS и прямой маршрут требуют разной обработки соединения.
4. Сохраняйте порядок кандидатов при применении разрешённого поведения отказа и резервирования.

CFNetworkExecuteProxyAutoConfigurationURL асинхронно загружает и оценивает скрипт. Его непосредственное возвращаемое значение — источник run loop. Запланируйте этот источник; после завершения работы обратный вызов передаёт результат оценки или ошибку. Создание источника и немедленное чтение пустой переменной результата ничего не ожидает. Аннулируйте источник, если операцию нужно отменить.

Держите целевой URL привязанным к запросу. Скрипт PAC может выбрать разные маршруты для двух хостов, поэтому сохранение одного разрешённого прокси в качестве ответа для каждого последующего назначения меняет политику скрипта. Точно так же прямой кандидат — это явный маршрут, а не отсутствующее имя хоста прокси.

Эти API полезны, когда пользовательский транспорт должен интерпретировать системные настройки. Они не реализуют последующий протокол прокси для этого транспорта, и запрос не извлекает пароли из Keychain. В macOS сопоставляйте учётные данные прокси в Keychain отдельно.