Novedades de WinHTTP 5.1

En este tema se describen las diferencias más importantes entre la versión 5.1 y la versión 5.0 de WinHTTP. Muchas de estas diferencias requieren cambios de código en las aplicaciones que migran de la versión 5.0 a la versión 5.1. Algunas de las características de la versión 5.1 solo están disponibles a partir de Windows Server 2003 y Windows XP con Service Pack 2 (SP2), especialmente características relacionadas con la mejora de la seguridad del cliente frente a servidores web malintencionados.

Importante

Con el lanzamiento de WinHTTP versión 5.1, la descarga de WinHTTP 5.0 ya no está disponible. A partir del 1 de octubre de 2004, Microsoft quitó la descarga del SDK de WinHTTP 5.0 y finalizó la compatibilidad del producto con la versión 5.0.

 

Cambio de nombre de DLL

El nombre del nuevo archivo DLL winHTTP 5.1 es Winhttp.dll, mientras que el nombre del archivo DLL winHTTP 5.0 es Winhttp5.dll.

WinHTTP 5.0 y 5.1 pueden coexistir en el mismo sistema; WinHTTP 5.1 no reemplaza ni se instala a través de WinHTTP 5.0.

Redistribución

WinHTTP 5.1 solo está disponible con Windows Server 2003, Windows 2000 Professional con Service Pack 3 (SP3), Windows XP con Service Pack 1 (SP1) y sistemas operativos posteriores. Un archivo de módulo de combinación redistribuible (.msm) no está disponible para WinHTTP 5.1.

WinHttpRequest ProgID

El ProgID del componente WinHttpRequest ha cambiado de "WinHttp.WinHttpRequest.5" a "WinHttp.WinHttpRequest.5.1". El CLSID de la clase WinHttpRequest también ha cambiado.

Cambio de comportamiento de devolución de llamada asincrónica

Al llamar a las funciones WinHttpWriteData, WinHttpQueryDataAvailable y WinHttpReadData en modo asincrónico, no confíe en que se establecerán los parámetros OUT lpdwNumberOfBytesWritten, lpdwNumberOfBytesAvailable e lpdwNumberOfBytesRead. Si la llamada de función se completa de forma asincrónica, WinHTTP no escribe en estos punteros proporcionados por el código de la aplicación. En su lugar, la aplicación debe recuperar estos valores mediante los parámetros lpvStatusInformation y dwStatusInformationLength de la función de devolución de llamada.

Cambios en la configuración predeterminada

Los cambios en la configuración predeterminada incluyen:

• La comprobación de certificados de servidor SSL está habilitada de forma predeterminada en WinHTTP 5.1. WinHTTP 5.0 no trata los errores detectados al validar el certificado de servidor como errores irrecuperables; se notifican a la aplicación mediante una notificación de devolución de llamada SECURE_FAILURE, pero eso no hace que se anule la solicitud. WinHTTP 5.1, en cambio, controla los errores de validación de certificados de servidor como errores irrecuperables que anulan la solicitud. La aplicación puede indicar a WinHTTP que omita un pequeño subconjunto de errores de certificado, como una CA desconocida, una fecha de certificado no válida o pasada o un nombre de sujeto de certificado no válido, mediante la opción WINHTTP_OPTION_SECURITY_FLAGS.
• La compatibilidad con la autenticación de Passport está deshabilitada de forma predeterminada en WinHTTP 5.1. La compatibilidad con Passport se puede habilitar con la opción WINHTTP_OPTION_CONFIGURE_PASSPORT_AUTH. La búsqueda automática de credenciales de Passport en Keyring también está deshabilitada de forma predeterminada.
• Cambio de comportamiento de redirección: los redireccionamientos HTTP de una dirección URL https: segura a una dirección URL http: normal ya no se siguen automáticamente de forma predeterminada por motivos de seguridad. Hay una nueva opción, WINHTTP_OPTION_REDIRECT_POLICY, para invalidar el comportamiento de redireccionamiento predeterminado en WinHTTP 5.1. Con el componente COM WinHttpRequest, use la nueva opción WinHttpRequestOption_EnableHttpsToHttpRedirects para habilitar los redireccionamientos de direcciones URL https: a http:.
• Cuando se crea un archivo de seguimiento winHTTP, el acceso se restringe con una ACL de modo que solo los administradores puedan leer o escribir el archivo. La cuenta de usuario con la que se creó el archivo de seguimiento también puede modificar la ACL para conceder acceso a otros usuarios. Esta protección solo está disponible en sistemas de archivos que admiten la seguridad; es decir, NTFS, no FAT32).
• A partir de Windows Server 2003 y Windows XP con SP2, el envío de solicitudes a los siguientes puertos conocidos y no HTTP está restringido por motivos de seguridad: 21 (FTP), 25 (SMTP), 70 (GOPHER), 110 (POP3), 119 (NNTP), 143 (IMAP).
• A partir de Windows Server 2003 y Windows XP con SP2, la cantidad máxima de datos de encabezado que WinHTTP acepta en una respuesta HTTP es de 64K de forma predeterminada. Si la respuesta HTTP del servidor contiene más de 64K de datos de encabezado totales, WinHTTP produce un error en la solicitud con un error ERROR_WINHTTP_INVALID_SERVER_RESPONSE. Este límite de 64K se puede invalidar mediante la nueva opción WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE.

Compatibilidad con IPv6

WinHTTP 5.1 agrega compatibilidad con el protocolo de Internet versión 6 (IPv6). WinHTTP puede enviar solicitudes HTTP a un servidor cuyo nombre DNS se resuelve en una dirección IPv6 y, a partir de Windows Server 2003 y Windows XP con SP2, WinHTTP también admite direcciones literales IPv6.

Nuevas opciones de la API de C/C++ para WinHTTP

WinHTTP 5.1 implementa las siguientes opciones nuevas:

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

A partir de Windows Server 2003 y Windows XP con SP2, WinHTTP 5.1 implementa las siguientes opciones nuevas. En Windows 2000 Professional con SP3 o Windows XP con SP1, sin embargo, se producen errores en las llamadas a WinHttpSetOption o WinHttpQueryOption con estos identificadores de opción:

"\#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"

Nuevas opciones en el componente WinHttpRequest 5.1

El componente WinHttpRequest 5.1 implementa las siguientes opciones nuevas:

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

Las siguientes opciones nuevas de WinHttpRequest 5.1 están disponibles a partir de Windows Server 2003 y Windows XP con SP2:

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

Los servidores proxy no son de confianza cuando la seguridad de inicio de sesión automático está establecida en Alta

En WinHTTP 5.0, los servidores proxy siempre son de confianza para el inicio de sesión automático. Esto ya no es válido para WinHTTP 5.1 que se ejecuta en Windows Server 2003 y Windows XP con SP2 cuando se establece la opción de directiva de WINHTTP_AUTOLOGON_SECURITY_LEVEL_HIGH.

API de detección automática de proxy web (AutoProxy)

Para facilitar la configuración de la configuración de proxy para las aplicaciones basadas en WinHTTP, WinHTTP ahora implementa el protocolo de detección automática de proxy web (WPAD), también conocido como autoproxy. Este es el mismo protocolo que implementan los exploradores web, como Internet Explorer, para detectar la configuración del proxy automáticamente sin necesidad de que un usuario final especifique manualmente un servidor proxy. Para admitir autoproxy, WinHTTP 5.1 implementa una nueva función de C/C++, WinHttpGetProxyForUrl, además de dos funciones compatibles, WinHttpDetectAutoProxyConfigUrl y WinHttpGetIEProxyConfigForCurrentUser.

Problemas conocidos

Se sabe que existen los siguientes problemas en WinHTTP 5.1 en Windows 2000 Professional con SP3 y Windows XP con SP1. Estos problemas se resuelven para WinHTTP a partir de Windows Server 2003 y Windows XP con SP2:

• Si la aplicación usa la función WinHttpSetTimeouts o el método SetTimeouts en el componente WinHttpRequest para establecer un tiempo de espera de resolución DNS no infinito, como el parámetro dwResolveTimeout, se produce una pérdida de identificador de subproceso cada vez que WinHTTP resuelve un nombre DNS. En un gran número de solicitudes HTTP, esto provoca una pérdida de memoria significativa. La solución consiste en dejar sin cambios la configuración predeterminada de tiempo de espera de resolución infinita (un valor de 0 especifica un tiempo de espera infinito). Este es el procedimiento más recomendado en cualquier caso, ya que admitir tiempos de espera en resoluciones de nombres DNS en WinHTTP es costoso en términos de rendimiento. Para Windows 2000 y versiones posteriores, establecer un tiempo de espera de resolución DNS en WinHTTP no es necesario, ya que el servicio cliente DNS subyacente implementa su propio tiempo de espera de resolución.
• Al procesar solicitudes asincrónicas, WinHTTP no controla correctamente la suplantación de subprocesos. Esto hace que se produzcan errores en las solicitudes que requieren autenticación NTLM/Negotiate, a menos que se proporcionen credenciales explícitamente mediante las funciones WinHttpSetCredentials o WinHttpSetOption.