WinINet vs. WinHTTP

Com algumas exceções, WinINet é um superconjunto de WinHTTP. Ao escolher entre os dois, você deve usar o WinINet a menos que planeje executá-lo em um serviço ou processo semelhante a um serviço que exija impersonação e isolamento de sessão.

Comparação de recursos

Característica WinINet WinHTTP
cache de credenciais. Permite que todos os aplicativos internos no Windows Internet Explorer obtenham credenciais automaticamente. Ele também permite que um aplicativo em execução fora do Internet Explorer solicite/especifique as credenciais para o servidor apenas uma vez. A partir daí, as solicitações são automáticas. Sim Não
solicitação de credencial. Fornece uma API que permite que o código de chamada solicite credenciais ao usuário. Sim Não
FTP Sim Não
Suporte a Autodial/RAS. Essa é uma funcionalidade herdada. Use Acesso Remoto em vez disso. Sim Não
Zonas. Integração automática com zonas de segurança do Internet Explorer. Sim Não
suporte à IDNA. Suporte integrado para a IDNA RFC/Punycode. Sim Sim
APIs do armazenamento de cookies. Há suporte para cookies persistentes e não persistentes. Qualquer aplicativo ou script pode usá-lo para ver os mesmos cookies que o navegador. Sim Não
Suporte ao IE em modo protegido Sim Não
suporte à descompactação. Suporte para os algoritmos de compressão gzip e deflate. Sim Sim
Suporte a upload fragmentado. O código do cliente deve realizar a fragmentação. Não Sim
suporte a SOCKS4 (SOCKS versão 4). Não inclui v4a. Sim Não
Suporte a SOCKS5 (SOCKS versão 5) Não Não
envio e recebimento bidirecional Não Não
E/S sobreposta Não Não
Suporte ao esquema de arquivo. Útil para scripts de proxy com um esquema de arquivo. Sim Não
InternetOpenUrl. Código simplificado para abrir uma URL. Sim Não
Suporte a serviços. Pode ser executado em um serviço ou em uma conta de serviço. Não Sim
isolamento de sessão. Sessões separadas não afetam umas às outras. Não Sim
Representação. Tem suporte para ser chamado enquanto o thread estiver representando um usuário diferente. Não Sim
  • WinINet
  • WinHTTP

Guia de decisão rápida

Use esse fluxograma para selecionar a pilha de clientes HTTP correta:

  1. Seu código está sendo executado em um serviço do Windows, processo do sistema ou sob representação?
    • Sim, → usar WinHTTP.
  2. Seu código é um aplicativo da área de trabalho que precisa das configurações de proxy, cookies ou solicitações de credencial do usuário no IE (Opções da Internet) ?
    • Sim, → usar WinINet.
  3. Você está desenvolvendo um aplicativo moderno para desktop em C++ ou um aplicativo UWP/WinUI?
  4. Você está escrevendo um aplicativo .NET?
    • Sim, → usar System.Net.Http.HttpClient.
  5. Você precisa de compatibilidade entre plataformas?
    • Sim → usar libcurl ou uma biblioteca portátil semelhante.

Note

Quando usar nem WinINet nem WinHTTP — se você estiver criando um novo aplicativo e não exigir integração herdada do Win32, prefira as alternativas modernas listadas acima. Eles oferecem APIs mais simples e melhor suporte assíncrono. Algumas alternativas também oferecem benefícios adicionais: libcurl e .NET HttpClient são multiplataforma; A disponibilidade do TLS 1.3 depende da pilha TLS subjacente e da configuração do sistema operacional. Reserve WinHTTP/WinINet para cenários que exigem especificamente suporte ao serviço Win32, compartilhamento de credenciais do navegador ou integração profunda de proxy.

Importante

Lembrete de segurança – independentemente de qual pilha HTTP você escolher, nunca desabilite a validação do certificado TLS em produção. Tanto o WinHTTP quanto o WinINet permitem ignorar erros de certificado por meio de sinalizadores, mas isso expõe sua aplicação a ataques de intermediário.

  • Last updated on