Creando conexión HTTP robusta para usuarios ficticios con WinINET

Question

Estoy haciendo un programa que descarga un archivo simple de Internet en Windows, usando Wininet Family API porque quiero utilizar su comportamiento de proxy compatible con IE. Como todos saben, el IE actual tiene varias configuraciones de proxy: detección automática (WPAD), configuración automática (PAC), URL individual de forma manual, servidores proxy por protocolo, calcetines, directo, ... Para la mayoría de los usuarios, la "descarga directa" " funciona bien; sin embargo, para algunos usuarios (especialmente los que están detrás de firewall/NAT), siempre necesitan configuraciones de proxy especiales cuando hacen conexiones.

Es doloroso escribir código para manejar todos estos casos, así que espero que WinINET con InternetOpen (INTERNET_OPEN_TYPE_PRECONFIG) me pueda ayudar. Lo hace para la mayoría de los usuarios, sin embargo, todavía encuentro algunos usuarios que se quejan de falla de conexión. Estos usuarios pueden tener entornos de red muy especiales (por ejemplo, necesitan autenticación de nombre de usuario/contraseña para el proxy) y la conexión directa no funciona para ellos.

A veces los usuarios ficticios tenían una configuración incorrecta, y me gustaría que Wininet probara "todas" las posibles configuraciones de proxy para mí; Desafortunadamente, el INTERNET_OPEN_TYPE_PRECONFIG solo probará el configurado por el usuario, no "todas las configuraciones de proxy posibles".

Así que mi pregunta es, ¿cómo puedo hacer un programa con mayor capacidad para solucionar todas las conexiones HTTP (especialmente para la configuración de proxy) para usuarios ficticios (es decir, no entienden cómo configurar su sistema)? ¿Hay alguna forma sugerida de hacer conexiones HTTP sin la necesidad de ocuparse de las cosas del proxy? (es decir, un solucionador de conexión "super" que intentará todas las configuraciones de proxy posibles), o si hay algún método para decirle a WinINET que habilite todas sus configuraciones de proxy para crear una conexión.

Answer 1

Un algoritmo razonable sería la siguiente:

1. intentar una conexión utilizando la configuración de proxy del usuario actual (los que usa IE). Estos son los más propensos a estar trabajando. Vea WinHttpGetIEProxyConfigForCurrentUser() en MSDN para obtener estas configuraciones, o INTERNET_OPEN_TYPE_PRECONFIG en WinINet.

2. si eso falla, intente con una conexión directa.

3. si eso falla, intente una autodetección WPAD usando WinHttpGetProxyForUrl. (WPAD es la forma automática en que los clientes pueden encontrar un archivo Proxy Auto-Config (PAC) en una red, generalmente una red corporativa). Deberá seleccionar la opción para verificar DHCP y DNS para el archivo proxy. WinHTTP AutoProxy Functions en MSDN contiene un ejemplo de código que usa esta API y mucha información de apoyo. Si esto tiene éxito, obtendrá la información del proxy que luego puede conectar a su código de descarga HTTP. AFAIK, no hay una opción de WinINet equivalente para hacer una nueva detección de WPAD automáticamente, solo WinHTTP.

4. A continuación puede intentar buscar la configuración del proxy de Firefox. This SO answer detalla información sobre la ubicación y el formato de estas configuraciones para que pueda acceder a ellas mediante programación.

5. si eso aún falla, solicite al usuario (en su IU) que compruebe que su conexión a Internet esté realmente conectada. en realidad, es mucho más común que los usuarios se desconecten que todos los pasos anteriores de detección de proxy que fallan. solicite al usuario que abra su navegador para asegurarse de que pueda acceder a un sitio de Internet. Si los pasos anteriores fallan, es probable que su navegador no pueda ver la Web. Una vez que el usuario dice que está conectado, repita los pasos 1-3.

6. si falla todo lo anterior, realmente no tiene más remedio que pedirle al usuario que especifique manualmente su información de proxy.Probablemente quiera clonar la interfaz de usuario del proxy de IE o Firefox, y convertir esas configuraciones de interfaz de usuario en los parámetros apropiados para configurar las opciones de proxy cuando descargue ese archivo.

Tenga en cuenta que no hay magia para aproximar detection-- sus opciones son utilizar la configuración del usuario, utilice la configuración del ordenador por defecto, utilice una conexión directa, utilizar WPAD para encontrar un archivo PAC, o preguntar al usuario. Desafortunadamente, no hay forma de "hacer conexiones HTTP sin la necesidad de ocuparse de las cosas del proxy".

BTW, aunque podría usar WinHTTP solo para la detección de proxy y luego usar WinINet para buscar el archivo, le sugiero que use WinHTTP para ambas partes. Cuando desee la mayor flexibilidad y control sobre su interacción HTTP (así como una mejor estabilidad que WinINet), WinHTTP es preferible.

ACTUALIZACIÓN 2:

JJ tenía una buena idea anterior-- Agregué un paso para verificar la configuración del proxy de Firefox. Dado que los poderes extraños generalmente se encuentran en entornos corporativos (que tienden a estandarizarse en IE) es menos probable que esto ayude, pero vale la pena intentarlo.

ACTUALIZACIÓN: que acaba de editar la sección anterior en respuesta a la observación correcta de Francis: WinHTTP no es el "sucesor" a WinINet en un sentido estricto (es decir, el 100% de las características de WinINet son algunos asientos en WinHTTP). Por el contrario, WinHTTP está diseñado para aplicaciones que utilizan HTTP para el intercambio de datos y no se preocupan por la integración con la memoria intermedia, las cookies, la interfaz de usuario de acceso telefónico, etc.

Las aplicaciones de servidor pertenecen definitivamente a esta categoría (WinHTTP, a diferencia de WinINet, es seguro para su uso en aplicaciones de servidor), pero muchos programas cliente también lo usan, por ejemplo, el cliente de Windows Update en todas las PC modernas. En general, WinHTTP es preferible para una aplicación cliente que necesita descargar archivos a través de HTTP y necesita un control más preciso sobre la red y desea controlar su propia IU.

WinHTTP es más práctico (por ejemplo, necesita hacer una llamada API para obtener información proxy y otra para usar esa información proxy) pero ese grado extra de control le permite hacer cosas que no puede hacer con WinINet, como forzar ignorar la configuración proxy del usuario y probar una nueva detección WPAD.

Answer 2

La mejor descripción que he encontrado del proceso que utiliza IE es en How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site. Combine la secuencia cuando usa IE para acceder a Windows Update con su conocimiento de WinINet o WinHTTP WinHttpGetIEProxyConfigForCurrentUser, WinHttpDetectAutoProxyConfigUrl, WinHttpGetProxyForUrl y WinHttpGetDefaultProxyConfiguration para conectar su aplicación.

Aquí está la secuencia del artículo de KB:

1. Si el usuario está configurado para detectar automáticamente la configuración, busque un archivo PAC mediante WPAD.
2. ¿No encontró el archivo PAC? Si el usuario tiene el conjunto de scripts de configuración automática de IE, use ese archivo PAC.
3. ¿Aún no se encontró el archivo PAC? Busque un proxy. Si el usuario ha configurado manualmente la configuración del proxy de IE, úselos.
4. ¿No está configurado el servidor proxy IE? Verifique la configuración predeterminada del proxy.
5. ¿No hay un proxy predeterminado configurado? Use una conexión directa.