Создание устойчивого HTTP-соединения для фиктивных пользователей с WinINET
Я делаю программу, которая загружает простой файл с Интернета в Windows, с помощью семейства Wininet API, потому что я хочу использовать его совместимое с IE поведение прокси. Как Вы все знаете, текущий IE имеет несколько настроек прокси: автоматическое обнаружение (WPAD), автоматическое конфигурирование (PAC), вручную единственный URL, прокси-серверы на протокол, носки, прямые... Для большинства пользователей хорошо работает "прямая загрузка"; однако для некоторых пользователей (особенно те, кто стоит за брандмауэром / NAT), им всегда нужны специальные настройки прокси при устанавливании связей.
Это болезненно для написания кода для обработки всех этих случаев, таким образом, я надеюсь что WinINET с InternetOpen (INTERNET_OPEN_TYPE_PRECONFIG) может помочь мне. Это делает для большинства пользователей, однако я все еще нахожу некоторых пользователей, жалующихся сбой соединения. Они у пользователя может быть совершенно особая сетевая среда (например, нуждайтесь в авторе имени пользователя/пароля для прокси), и прямое подключение не работает на них.
Иногда у фиктивных пользователей была неправильная конфигурация, и я хотел бы, чтобы wininet попробовал "все" возможные настройки прокси за меня; к сожалению, INTERNET_OPEN_TYPE_PRECONFIG только попробует тот, который пользователь настроил, не "каждый возможные настройки прокси".
Таким образом, мой вопрос, как я делаю программу с самой сильной способностью к обходному решению всем http соединением (специально для конфигурации прокси) для фиктивных пользователей (т.е., они не понимают, как настроить их систему)? Там кому-либо предлагают способ сделать HTTP-соединения без потребности заботиться о материале прокси? (т.е. "супер" решатель соединения, который попробует все возможные настройки прокси), или если существует какой-либо метод, чтобы сказать WinINET позволять всем его настройкам прокси создать соединение?
1 ответ
Разумным алгоритмом было бы следующее:
попробовать соединение, используя текущие настройки прокси пользователя (те, которые использует IE). Это те, которые больше всего нравятся для работы. Смотрите
WinHttpGetIEProxyConfigForCurrentUser()на MSDN, чтобы получить эти настройки, илиINTERNET_OPEN_TYPE_PRECONFIGв WinINet. Если это не удается, попробуйте прямое соединение.если это не удается, попробуйте автоопределение WPAD, используя WinHttpGetProxyForUrl. (WPAD - это автоматический способ, с помощью которого клиенты могут найти Прокси-автоконфигурационный файл (PAC) в сети, обычно в корпоративной сети). Для прокси-файла необходимо выбрать опцию проверки и DHCP, и DNS.
Функции автопроксирования WinHTTPна MSDN содержат пример кода, использующего этот API и много поддерживающей информации. Если это удастся, вы получите обратно информацию о прокси, который вы можете подключить к вашему HTTP коду загрузки. AFAIK, нет эквивалентной опции WinINet для автоматического определения нового WPAD - только WinHTTP.Далее вы можете попробовать поискать настройки прокси Firefox. Этот ответ по SO содержит подробную информацию о местоположении и формате этих настроек, чтобы вы могли получить к ним программный доступ. Если это все еще не удается, попросите пользователя (в вашем пользовательском интерфейсе) проверить, что его интернет соединение действительно подключено. на самом деле гораздо чаще пользователи отключаются, чем на всех вышеописанных шагах по обнаружению прокси-серверов. попросите пользователя открыть его браузер, чтобы убедиться, что он может добраться до интернет сайта - если вышеописанные шаги не удаются, его браузер, как будто, не может видеть интернет. Как только пользователь заявит, что он подключен, повторите шаги 1-3. Если все вышеперечисленные шаги не дают результата, у вас действительно нет другого выбора, кроме как попросить пользователя вручную указать информацию о прокси-сервере. Вы, вероятно, захотите клонировать UI прокси IE или firefox, и включить эти настройки UI в соответствующие параметры, чтобы настроить опции прокси при загрузке этого файла.
Обратите внимание, что нет никакой магии в обнаружении прокси - ваш выбор - использовать настройки пользователя, использовать настройки компьютера по умолчанию, использовать прямое соединение, использовать WPAD для поиска PAC-файла, или попросить пользователя. К сожалению, нет способа "делать HTTP соединения без необходимости заботиться о прокси".
BTW, хотя вы можете использовать WinHTTP только для обнаружения прокси, а затем использовать WinINet для получения файла, я бы предложил использовать WinHTTP для обеих частей. Когда вы хотите наибольшую гибкость и контроль над вашим HTTP взаимодействием (а также лучшую стабильность, чем WinINet), предпочтительнее использовать WinHTTP.
UPDATE 2:
J.J. была хорошая идея выше - я добавил шаг для проверки настроек прокси Firefox. Так как нечетные прокси обычно встречаются в корпоративных средах (которые имеют тенденцию к стандартизации на IE). несколько менее похоже на то, что это поможет, но стоит попробовать.
UPDATE: Я только что отредактировал раздел выше в ответ на правильный комментарий Фрэнсиса: WinHTTP не является "преемником" WinINet в строгом смысле этого слова (это означает, что 100% возможностей WinINet доступны в WinHTTP). Скорее, WinHTTP предназначен для приложений, использующих HTTP для обмена данными и не заботящихся об интеграции с кэшем Interet Explorer, куки-файлами, dial-up UI и др.
Серверные приложения определенно попадают в эту категорию (WinHTTP, в отличие от WinINet, безопасен для использования в серверных приложениях), но многие клиентские программы также используют его, например, клиент Windows Update на каждом современном ПК. В общем, WinHTTP предпочтительнее для клиентского приложения, которому нужно загружать файлы по HTTP и который нуждается в более тонком контроле над сетью и хочет контролировать свой собственный пользовательский интерфейс.
WinHTTP более практичен (например, вам нужно сделать один API вызов, чтобы получить информацию о прокси, а другой - чтобы использовать эту информацию о прокси), но эта дополнительная степень контроля позволяет вам делать вещи, которые вы не можете сделать с помощью WinINet, например, заставить игнорировать настройки прокси пользователя и попробовать новое обнаружение WPAD.
.