WinINet и WinHTTP

За некоторыми исключениями, WinINet является супермножеством WinHTTP. При выборе между этими двумя вам следует использовать WinINet если только вы не планируете запуск в службе или в процессе, подобном службе, где требуется имперсонация и изоляция сеансов.

Сравнение функций

Особенность WinINet WinHTTP
Кэш учетных данных. Позволяет всем встроенным приложениям в Windows Internet Explorer автоматически получать учетные данные. Он также позволяет приложению, работающему за пределами Internet Explorer, запрашивать или указывать учетные данные сервера только один раз. После этого запросы автоматически. да Нет
Запрос учетных данных. Предоставляет API, который позволяет вызывающему коду запрашивать у пользователя учетные данные. да Нет
FTP да Нет
Поддержка автодозвона/RAS. Это устаревшая функция. Используйте Удаленный доступ вместо этого. да Нет
Зоны. Автоматическая интеграция с зонами безопасности Internet Explorer. да Нет
Поддержка IDNA. Встроенная поддержка IDNA RFC/Punycode. да да
API JAR-файлов cookie. Поддерживаются постоянные и непрекращающиеся файлы cookie. Любое приложение или скрипт может использовать это, чтобы увидеть те же файлы cookie, что и браузер. да Нет
поддержка защищенного режима IE да Нет
поддержка декомпрессии. Поддержка схемы сжатия gzip и deflate. да да
Поддержка загрузки по частям. Клиентский код должен выполнять разбиение на фрагменты. Нет да
поддержка SOCKS4 (SOCKS версии 4). Не включает v4a. да Нет
поддержка SOCKS5 (SOCKS версии 5) Нет Нет
двунаправленная отправка и получение Нет Нет
перекрывающихся операций ввода-вывода Нет Нет
Поддержка схемы file. Полезно для прокси-скриптов с файловой схемой. да Нет
InternetOpenUrl. Упрощенный код для открытия URL-адреса. да Нет
Поддержка служб. Можно запускать из службы или учетной записи службы. Нет да
Изоляция сеансов. Отдельные сеансы не влияют друг на друга. Нет да
олицетворение. Поддерживает вызов в ситуации, когда поток выполняется от имени другого пользователя. Нет да

Краткое руководство по принятию решений

Используйте эту блок-схему для выбора правильного стека клиента HTTP:

  1. Выполняется ли ваш код в службе Windows, системном процессе или с использованием олицетворения?
    • Да → использовать WinHTTP.
  2. Является ли ваш код настольным приложением, которому требуются настройки прокси-сервера из параметров Internet Explorer (IE), файлы cookie или запросы учетных данных?
    • Да, → использовать WinINet.
  3. Вы пишете современное классическое приложение C++ или приложение UWP/WinUI?
    • Да → используйте Windows.Web.Http (C++/WinRT через пространство имен Windows.Web.Http).
  4. Вы пишете .NET приложение?
    • Да → использовать System.Net.Http.HttpClient.
  5. Нужна ли кроссплатформенная совместимость?
    • Да → Использовать libcurl или аналогичную переносимую библиотеку.

Note

Когда не следует использовать ни WinINet, ни WinHTTP — если вы разрабатываете новое приложение и вам не требуется интеграция с устаревшим Win32, отдавайте предпочтение современным альтернативам, перечисленным выше. Они предлагают более простые API и более эффективную асинхронную поддержку. Некоторые альтернативные варианты также предлагают дополнительные преимущества: libcurl и .NET HttpClient являются кроссплатформенными; Доступность TLS 1.3 зависит от базовой конфигурации TLS и конфигурации ОС. Резервировать WinHTTP/WinINet для сценариев, для которых требуется поддержка службы Win32, общий доступ к учетным данным браузера или глубокая интеграция прокси-сервера.

Important

Напоминание о безопасности . Независимо от выбранного стека HTTP никогда не отключайте проверку сертификата TLS в рабочей среде. Как WinHTTP, так и WinINet позволяют игнорировать ошибки сертификатов с помощью соответствующих флагов, однако это делает приложение уязвимым для атак типа «человек посередине».