Novedades de WinHTTP 5.1

  • Artículo

En este tema se describen las diferencias más importantes entre WinHTTP versión 5.1 y la versión 5.0. 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 contra 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 ha quitado la descarga del SDK de WinHTTP 5.0 de MSDN y ha finalizado la compatibilidad con productos para 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 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 se basan en los parámetros lpdwNumberOfBytesWritten, lpdwNumberOfBytesAvailable y lpdwNumberOfBytesRead OUT que se van a establecer. 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 a 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 del certificado de servidor SSL está habilitada de forma predeterminada en WinHTTP 5.1. WinHTTP 5.0 no controla 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 no hace que se anule la solicitud. WinHTTP 5.1, como alternativa, 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 entidad de certificación desconocida, una fecha de certificado no válida o un nombre de firmante 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: las redirecciones HTTP desde una dirección HTTPS segura: la dirección URL a un http normal ya no se sigue 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 de WinHttpRequestOption_EnableHttpsToHttpRedirects para habilitar las redirecciones de https: a http: url.
  • 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 a otros usuarios acceso. 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 64K, de forma predeterminada. Si la respuesta HTTP del servidor contiene más de 64 000 de datos de encabezado totales, WinHTTP produce un error de ERROR_WINHTTP_INVALID_SERVER_RESPONSE . Este límite de 64K se puede invalidar mediante la nueva opción de 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 en 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\\_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 nuevas opciones 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 los valores 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 los exploradores web, como Internet Explorer, implementan para detectar la configuración de 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 de DNS no infinito, como el parámetro dwResolveTimeout , se produce una fuga 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 alternativa consiste en dejar el valor de tiempo de espera de resolución infinito predeterminado sin cambios (un valor de 0 especifica un tiempo de espera infinito). Esto se recomienda encarecidamente 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 de 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 las credenciales se especifiquen explícitamente mediante las funciones WinHttpSetCredentials o WinHttpSetOption .