Novidades no WinHTTP 5.1

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

Alteração de nome DLL

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

O WinHTTP 5.0 e o 5.1 podem coexistir no mesmo sistema; o WinHTTP 5.1 não substitui nem se sobrepõe ao WinHTTP 5.0.

Redistribuição

O WinHTTP 5.1 está disponível somente com o Windows Server 2003, Windows 2000 Professional com Service Pack 3 (SP3), Windows XP com Service Pack 1 (SP1) e sistemas operacionais 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 mudou de "WinHttp.WinHttpRequest.5" para "WinHttp.WinHttpRequest.5.1". O CLSID da classe WinHttpRequest também mudou.

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

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

Mudanças nas configurações padrão

As mudanças nas configurações padrão incluem:

• A verificação de certificado do servidor SSL é ativada por padrão no WinHTTP 5.1. O WinHTTP 5.0 não lida com falhas encontradas ao validar o certificado do servidor como erros fatais; eles são relatados ao aplicativo usando uma notificação de retorno de chamada SECURE_FAILURE, mas não faz com que a solicitação seja anulada. O WinHTTP 5.1, como alternativa, lida com as falhas de validação de certificado do 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á desabilitado por padrão no WinHTTP 5.1. O suporte ao Passaporte pode ser ativado com a opção WINHTTP_OPTION_CONFIGURE_PASSPORT_AUTH. A pesquisa automática de credenciais do Passaporte no Keyring também está desativada por padrão.
• Alteração no comportamento de redirecionamento: redirecionamentos HTTP de uma URL https: segura para uma URL http: normal 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 COM WinHttpRequest, use a nova opção WinHttpRequestOption_EnableHttpsToHttpRedirects para habilitar redirecionamentos de URLs https: para http:.
• Quando um arquivo de rastreamento WinHTTP é criado, o acesso é restrito com uma ACL, para que somente os administradores possam ler ou gravar o arquivo. A conta de usuário na qual o arquivo de rastreamento foi criado também pode modificar a ACL para dar acesso a outras pessoas. Essa proteção está disponível somente em sistemas de arquivos que suportam segurança; isto é, NTFS, não FAT32).
• A partir do Windows Server 2003 e do Windows XP com SP2, o envio de solicitações às 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 quantia máxima de dados de cabeçalho que o WinHTTP aceita em uma resposta HTTP é de 64 K, por padrão. Se a resposta HTTP do servidor contiver mais de 64 K de dados totais de cabeçalho, o WinHTTP falhará na solicitação com um erro ERROR_WINHTTP_INVALID_SERVER_RESPONSE. Esse limite de 64 K pode ser substituído usando a nova opção WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE.

Suporte a IPv6

O WinHTTP 5.1 dá suporte para IPv6 (Internet Protocol Version 6). O WinHTTP pode enviar solicitações HTTP a 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 dá suporte a endereços literais IPv6.

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

O WinHTTP 5.1 implementa estas 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 seguintes novas opções. Porém, no Windows 2000 Professional com SP3 ou Windows XP com SP1, 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 estas 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 do Windows XP com SP2:

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

Os proxies não são confiáveis quando a segurança de logon automático é definida como alta

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

API de Descoberta automática de proxy da Web (AutoProxy)

Para facilitar a definição de configurações de proxy para aplicativos com base 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 precisar que um usuário final especifique um servidor proxy manualmente. Para dar suporte ao proxy automático, o WinHTTP 5.1 implementa uma nova função C/C++, WinHttpGetProxyForUrl,mais duas funções de suporte, WinHttpDetectAutoProxyConfigUrl e WinHttpGetIEProxyConfigForCurrentUser.

Problemas conhecidos

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

• Se o aplicativo usar a função WinHttpSetTimeouts ou o método SetTimeouts no componente WinHttpRequest para definir um tempo limite de resolução de DNS não infinito, como o parâmetro dwResolveTimeout, um vazamento de identificador de thread ocorre sempre que o WinHTTP resolve um nome DNS. Em um número grande 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 0 especifica um tempo limite infinito). Isso é altamente recomendado de qualquer forma, pois o suporte a tempos limite em resoluções de nomes DNS no WinHTTP custa muito em termos de performance. Para o Windows 2000 e posterior, definir um tempo limite de resolução 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 trata da 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 fornecidas explicitamente usando as funções WinHttpSetCredentials ou WinHttpSetOption.