Una vez abierta una instancia en el API, el modo más sencillo de acceder a los datos remotos es a través de la llamada a una sola función: InternetOpenUrl.
Esta función, se encargará se decidir el tipo de protocolo a utilizar (dependiendo de la URL que le pasemos) y darnos acceso a un recurso remoto. Por esta razón, podemos utilizar esta función con cualquier protocolo de los soportados por Wininet, y no solamente HTTP.
InternetOpenUrl está pensada para aquellos casos en que no es necesario utilizar alguna característica especial del protocolo (como crear carpetas con FTP o enviar un formulario con HTTP), sino que símplemente nos basta con acceder a los datos del recurso.
Internamente, esta función hace distintas operaciones, que veremos desglosadas cuando hablemos sobre el método detallado.
La sintaxis es la siguiente:
HINTERNET InternetOpenUrl(
HINTERNET hInternet,
LPCTSTR lpszUrl,
LPCTSTR lpszCabeceras,
DWORD dwLongitudCabeceras,
DWORD dwOpciones,
DWORD dwContexto
);
~- hInternet: un descriptor que hemos obtenido a través de la llamada a InternetOpen.
~- lpszUrl: un puntero a cadena que contiene la URL a la que queremos acceder. Esta URL debe contener obligatoriamente los componentes: protocolo, servidor y recurso, aunque opcionalmente podemos incluír también el puerto, usuario y contraseña, y parámetros adicionales. Un buen método de crear esta URL es a través de la función InternetCreateUrl, explicada en nuestro anterior artículo. Dado que Wininet sólo soporta 3 protocolos, esta URL sólo puede comenzar por gopher://, ftp://, http:// y https://
~- lpszCabeceras: es un puntero a una cadena con la que podemos enviar cabeceras adicionales en la petición HTTP. Por ejemplo, podríamos crear nuestra propia cabecera y enviarla desde un cliente que utilice WinInet, para que, al otro lado de la línea, el servidor HTTP interprete esta cabecera de un modo especial. En este caso, nos estaríamos saliendo del estándar definido por HTTP. En caso de no necesitar cabeceras adicionales (lo más habitual para un uso normal del protocolo), debemos pasar el valor NULL.
~- dwLongitudCabeceras: el número de caracteres de las cabeceras adicionales pasadas en lpszCabeceras. Si pasamos el valor -1, y lpszCabeceras es distinto de NULL, la función calculará la longitud correcta (buscando el carácter nulo final). Este parámetro se ignorará si hemos pasado el valor NULL en lpszCabeceras.
~- dwOpciones: en este parámetro podemos configurar el comportamiento. A continuación explico algunos de los valores posibles, aunque sólo incluyo aquellos que tienen alguna utilidad en el protocolo HTTP. Cuando hablemos del protocolo FTP daremos un repaso a esta función, explicando el resto de los valores posibles:
~~- INTERNET_FLAG_HYPERLINK: obliga a descargar el recurso cuando el servidor no haya retornado valores de caducidad o última modificación (claves "Expires" y "Last-modified" de las cabeceras del protocolo).
~~- INTERNET_FLAG_NO_AUTO_REDIRECT: Wininet, por defecto, gestiona las redirecciones de forma transparente. De este modo, si el recurso al que queremos acceder nos redirecciona a otro, en realidad accederemos al segundo. Incluyendo este valor, obligamos a que Wininet no gestione estas redirecciones, dejando la situación en manos del programador.
~~- INTERNET_FLAG_IGNORE_REDIRECT_TO_HTTP: Cancela las redirecciones desde una conexión segura (HTTPS) a una conexión normal (HTTP).
~~- INTERNET_FLAG_IGNORE_REDIRECT_TO_HTTPS: este parámetro es igual que el anterior, pero en sentido contrario, es decir: una redirección de una conexión normal a una conexión segura.
~~- INTERNET_FLAG_NEED_FILE: si el recurso no puede ser almacenado en el caché, se guardará en un archivo temporal.
~~- INTERNET_FLAG_NO_CACHE_WRITE: no almacena el recurso en el caché de datos.
~~- INTERNET_FLAG_NO_COOKIES: ignora todas las peticiones de cookies que haga el recurso al que estamos accediendo, ya sean de lectura o grabación.
~~- INTERNET_FLAG_NO_UI: Cuando se intenta crear una cookie, y hemos configurado Internet Explorer para pedir confirmación (según el nivel de seguridad establecido en Panel de control - Opciones de Internet - Seguridad), se muestra al usuario una ventana de diálogo pidiendo confirmación. Si incluímos este valor, se ignorará esta ventana.
~~- INTERNET_FLAG_PRAGMA_NOCACHE: obliga a descargar el recurso del servidor original, incluso si existe una copia en el caché de algún servidor proxy intermedio. A propósito de esto: podríamos utilizar esta bandera para evitar uso del proxy-caché que ha instalado Telefónica a todos sus clientes de ADSL, aunque mucho me temo que Internet Explorer no hace.
~~- INTERNET_FLAG_RELOAD: fuerza a descargar el recurso del servidor original, aunque exista una copia en nuestro caché local.
~~- INTERNET_FLAG_RESYNCHRONIZE: obliga a volver a sincronizar el contenido del caché local con los datos del servidor original.
~~- INTERNET_FLAG_SECURE: establece una conexión segura, utilizando la extensión SSL (Secure Socket Layer). Para utilizar una conexión segura, debemos tener correctamente instalada la extensión para canales seguros, incluída en la librería "schannel.dll". La versión más sencilla de esta librería se incluye a partir de Windows 95 ORS2.
~- dwContexto: este valor se utilizará para pasarlo a la función de "callback" en las conexiones asíncronas (pasando INTERNET_FLAG_ASYNC en el parámetro dwOpciones de la función InternetOpen). Normalmente podremos pasar un puntero a una estructura donde almacenamos datos sobre la conexión, el estado de la descarga, etc. Para conexiones síncronas (por defecto), este parámetro se ignorará, por lo que debemos pasar el valor 0.
Esta función retornará un descriptor válido si la conexión ha sido establecida o NULL si ha ocurrido un error (en este caso podemos utilizar GetLastError para obtener el código de error).
Si hemos conseguido acceder correctamente a la Url, el siguiente paso es leer directamente de los recursos remotos, utilizando las funciones que explicamos a continuación.
