O que há de novo no WinHTTP 5.1

2025-03-25

Este tópico descreve as diferenças mais importantes entre WinHTTP versão 5.1 e versão 5.0. Muitas dessas diferenças exigem alterações de código em aplicativos que migram da versão 5.0 para a versão 5.1. Alguns dos recursos da versão 5.1 só estão disponíveis a partir do Windows Server 2003 e do Windows XP com Service Pack 2 (SP2), particularmente recursos relacionados à melhoria da segurança do cliente contra servidores Web mal-intencionados.

Importante

Com o lançamento do WinHTTP versão 5.1, o download do WinHTTP 5.0 não está mais disponível. A partir de 1 de outubro de 2004, a Microsoft removeu o download do WinHTTP 5.0 SDK e encerrou o suporte ao produto para a versão 5.0.

Alteração de nome DLL

O nome da nova DLL WinHTTP 5.1 é Winhttp.dll, enquanto o nome da DLL WinHTTP 5.0 é Winhttp5.dll.

WinHTTP 5.0 e 5.1 podem coexistir no mesmo sistema; WinHTTP 5.1 não substitui, ou instala sobre, WinHTTP 5.0.

Redistribuição

O WinHTTP 5.1 está disponível apenas com sistemas operacionais Windows Server 2003, Windows 2000 Professional com Service Pack 3 (SP3), Windows XP com Service Pack 1 (SP1) e posteriores. Um arquivo de módulo de mesclagem redistribuível (.msm) não está disponível para WinHTTP 5.1.

WinHttpRequest ProgID

O ProgID do componente WinHttpRequest foi alterado de "WinHttp.WinHttpRequest.5" para "WinHttp.WinHttpRequest.5.1". O CLSID da classe WinHttpRequest também foi alterado.

Alteração do comportamento de retorno de chamada assíncrona

Ao chamar as funções WinHttpWriteData, WinHttpQueryDataAvailable e WinHttpReadData no modo assíncrono, não confie que os respetivos parâmetros OUT lpdwNumberOfBytesWritten, lpdwNumberOfBytesAvailable, e lpdwNumberOfBytesRead sejam configurados. Se a chamada de função for concluída de forma assíncrona, o WinHTTP não gravará nesses ponteiros fornecidos pelo código do aplicativo. Em vez disso, a aplicação deve recuperar esses valores usando os parâmetros lpvStatusInformation e dwStatusInformationLength para a função de retorno de chamada.

Alterações nas configurações padrão

As alterações nas configurações padrão incluem:

A verificação de certificado do servidor SSL está habilitada por padrão no WinHTTP 5.1. WinHTTP 5.0 não lida com falhas encontradas ao validar o certificado do servidor como erros fatais; são reportadas ao aplicativo usando uma notificação de retorno de chamada SECURE_FAILURE, mas não fazem com que a solicitação seja abortada. WinHTTP 5.1, como alternativa, lida com falhas de validação de certificado de servidor como erros fatais que anulam a solicitação. O aplicativo pode instruir o WinHTTP a ignorar um pequeno subconjunto de erros de certificado, como CA desconhecida, data de certificado inválida/expirada ou nome de entidade de certificado inválido, usando a opção WINHTTP_OPTION_SECURITY_FLAGS.
O suporte à autenticação do Passport está desativado por padrão no WinHTTP 5.1. O suporte de passaporte pode ser ativado com a opção WINHTTP_OPTION_CONFIGURE_PASSPORT_AUTH. A pesquisa automática de credenciais do Passport no porta-chaves também está desativada por padrão.
Mudança de comportamento de redirecionamento: HTTP redireciona de um seguro https: URL para um regular http: URL não são mais seguidos automaticamente por padrão por motivos de segurança. Há uma nova opção, WINHTTP_OPTION_REDIRECT_POLICY, para substituir o comportamento de redirecionamento padrão no WinHTTP 5.1. Com o componente WinHttpRequest COM, use a nova opção WinHttpRequestOption_EnableHttpsToHttpRedirects para ativar redirecionamentos de https: para http: URLs.
Quando um arquivo de rastreamento WinHTTP é criado, o acesso é restrito com uma ACL para que apenas os administradores possam ler ou gravar o arquivo. A conta de usuário sob a qual o arquivo de rastreamento foi criado também pode modificar a ACL para conceder acesso a outras pessoas. Esta proteção só está disponível em sistemas de ficheiros que suportem segurança; ou seja, NTFS, não FAT32).
A partir do Windows Server 2003 e do Windows XP com SP2, o envio de solicitações para as seguintes portas conhecidas e não HTTP é restrito por motivos de segurança: 21 (FTP), 25 (SMTP), 70 (GOPHER), 110 (POP3), 119 (NNTP), 143 (IMAP).
A partir do Windows Server 2003 e do Windows XP com SP2, a quantidade máxima de dados de cabeçalho que o WinHTTP aceita em uma resposta HTTP é 64K, por padrão. Se a resposta HTTP do servidor contiver mais de 64K do total de dados de cabeçalho, o WinHTTP falhará a solicitação com um erro de ERROR_WINHTTP_INVALID_SERVER_RESPONSE. Este limite de 64K pode ser ultrapassado usando a nova opção WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE.

Suporte a IPv6

WinHTTP 5.1 adiciona suporte para Internet Protocol Version 6 (IPv6). O WinHTTP pode enviar solicitações HTTP para um servidor cujo nome DNS é resolvido em um endereço IPv6 e, a partir do Windows Server 2003 e do Windows XP com SP2, o WinHTTP também oferece suporte a endereços literais IPv6.

Novas opções na API C/C++ para WinHTTP

WinHTTP 5.1 implementa as seguintes novas opções:

#define WINHTTP\_OPTION\_PASSPORT\_SIGN\_OUT 86 #define WINHTTP\_OPTION\_PASSPORT\_RETURN\_URL 87 #define WINHTTP\_OPTION\_REDIRECT\_POLICY 88

A partir do Windows Server 2003 e do Windows XP com SP2, o WinHTTP 5.1 implementa as novas opções a seguir. No Windows 2000 Professional com SP3 ou Windows XP com SP1, no entanto, as chamadas para WinHttpSetOption ou WinHttpQueryOption com estas IDs de opção falham:

"\#define WINHTTP\_OPTION\_RECEIVE\_RESPONSE\_TIMEOUT 7" "\#define WINHTTP\_OPTION\_MAX\_HTTP\_AUTOMATIC\_REDIRECTS 89" "\#define WINHTTP\_OPTION\_MAX\_HTTP\_STATUS\_CONTINUE 90" "\#define WINHTTP\_OPTION\_MAX\_RESPONSE\_HEADER\_SIZE 91" "\#define WINHTTP\_OPTION\_MAX\_RESPONSE\_DRAIN\_SIZE 92"

Novas opções no componente WinHttpRequest 5.1

O componente WinHttpRequest 5.1 implementa as seguintes novas opções:

WinHttpRequestOption\_RevertImpersonationOverSsl" "WinHttpRequestOption\_EnableHttpsToHttpRedirects" "WinHttpRequestOption\_EnablePassportAuthentication

As seguintes novas opções WinHttpRequest 5.1 estão disponíveis a partir do Windows Server 2003 e Windows XP com SP2:

"WinHttpRequestOption\_MaxAutomaticRedirects" "WinHttpRequestOption\_MaxResponseHeaderSize" "WinHttpRequestOption\_MaxResponseDrainSize" "WinHttpRequestOptions\_EnableHttp1\_1"

Proxies não são confiáveis quando a segurança de logon automático está definida como alta

No WinHTTP 5.0, os servidores proxy são sempre confiáveis para logon automático. Isso não é mais válido para WinHTTP 5.1 em execução no Windows Server 2003 e Windows XP com SP2 quando a opção de diretiva WINHTTP_AUTOLOGON_SECURITY_LEVEL_HIGH é definida.

API de Descoberta Automática de Proxy da Web (AutoProxy)

Para facilitar a configuração de configurações de proxy para aplicativos baseados em WinHTTP, o WinHTTP agora implementa o protocolo Web Proxy Auto-Discovery (WPAD), também conhecido como autoproxy. Este é o mesmo protocolo que os navegadores da Web, como o Internet Explorer, implementam para descobrir a configuração de proxy automaticamente sem exigir que um usuário final especifique um servidor proxy manualmente. Para suportar autoproxy, WinHTTP 5.1 implementa uma nova função C/C++, WinHttpGetProxyForUrl, além de duas funções de suporte, WinHttpDetectAutoProxyConfigUrl e WinHttpGetIEProxyConfigForCurrentUser.

Problemas conhecidos

Os seguintes problemas são conhecidos por existirem no WinHTTP 5.1 no Windows 2000 Professional com SP3 e Windows XP com SP1. Estes problemas são resolvidos para WinHTTP a partir do Windows Server 2003 e Windows XP com SP2:

Se a aplicação utiliza a função WinHttpSetTimeouts ou o método SetTimeouts no componente WinHttpRequest para definir um tempo limite de resolução DNS não infinito, como o parâmetro dwResolveTimeout, ocorre uma perda de identificador de thread sempre que o WinHTTP resolve um nome DNS. Em um grande número de solicitações HTTP, isso causa um vazamento de memória significativo. A solução alternativa é deixar a configuração padrão de tempo limite de resolução infinita inalterada (um valor de 0 especifica um tempo limite infinito). Isso é altamente recomendado em qualquer caso, pois o suporte a tempos limite em resoluções de nomes DNS no WinHTTP é caro em termos de desempenho. Para o Windows 2000 e versões posteriores, definir um tempo limite de resolução de DNS no WinHTTP é desnecessário, pois o serviço de cliente DNS subjacente implementa seu próprio tempo limite de resolução.
Ao processar solicitações assíncronas, o WinHTTP não manipula a representação de thread corretamente. Isso faz com que as solicitações que exigem autenticação NTLM/Negotiate falhem, a menos que as credenciais sejam explicitamente fornecidas usando as funções WinHttpSetCredentials ou WinHttpSetOption.