Como ya dijimos, Wininet soporta tres protocolos de aplicación: HTTP, FTP y Gopher. Sin duda alguna, podemos decir que el más importante y utilizado de todos ellos es HTTP, ya que todos los sitios web visitados (y la mayoría de los archivos descargados desde el navegador) de internet son recuperados a través de este protocolo.

HTTP permite la transferencia de múltiples tipos de información de una forma eficiente, haciéndolo idóneo para una red tan hetereogénea como internet, donde los formatos en que se presenta la información son muy variados e impredecibles (páginas HTML, programas, imágenes, sonidos, videos, películas Flash, futuros formatos, etc.).

La estructura del protocolo HTTP es sencilla, más o menos como la de cualquier arquitectura cliente/servidor:
La máquina cliente establece una conexión (normalmente a través del protocolo de transporte TCP/IP, al puerto 80) con la máquina servidora, donde está ejecutándose un software llamado servidor web o servidor HTTP (Apache o Internet Information Server son algunos de ellos).
Una vez establecida la conexión, el cliente (por ejemplo el navegador web) envía tramas de datos que consisten en unas cabeceras especiales y una petición, que es recibida al otro lado de la conexión por el servidor HTTP.
Este servidor interpretará la petición del cliente, devolviendo un resultado, que dependerá del tipo de petición recibida.
Una vez que la respuesta ha sido enviada, la conexión se pierde. Es por esto que el protocolo HTTP se denomina "sin conexión", al contrario que otros como FTP que mantienen una conexión abierta continuamente. Además de ser "sin conexión", también se suele decir que es un protocolo "sin estado", ya que no tiene en cuenta peticiones anteriores de un mismo cliente, y considera que cada petición es única e independiente del resto.

El API Wininet nos permite enviar y recibir peticiones, a través de distintos protocolos, simplemente llamando a ciertas funciones, sin tener que preocuparnos de la estructura petición/respuesta que acabamos de ver.

Para ello, se cuenta con una serie de funciones para operaciones comunes, que se utilizarán siempre que vayamos a acceder al API, independientemente del protocolo a utilizar. Estas funciones comienzan por la palabra "Internet". Una vez realizadas estas operaciones, el programador tiene dos opciones: un método directo, que nos permite conectar con un recurso remoto, llamando símplemente a una función, o un método detallado, a través del cual tendremos que recorrer varios pasos hasta poder acceder al recurso. En este último caso, debemos decantarnos por uno de los protocolos disponibles, llamando unas funciones u otras dependiendo del protocolo elegido. Una vez hecho esto, lo último que queda por hacer es leer datos del recurso remoto, ya sean datos informativos (de cabecera) o los datos del recurso en sí (una página web, una imágen, etc).

En la siguiente figura podemos ver esta secuencia que acabamos de explicar:

En este artículo vamos a entrar en las partes comunes (operaciones comunes y lectura de datos) y en el método directo. Dejaremos para siguientes artículos el método detallado para HTTP y FTP.

Antes de comenzar a enviar peticiones a través del API Wininet, es necesario realizar una serie de operaciones para preparar las estructuras internas. Estas operaciones son generales en el uso de WinInet, es decir: se tendrán que realizan tanto si queremos establecer una conexión HTTP, FTP o Gopher.

Antes de cualquier intento de conexión, es muy recomendable asegurarnos de que el equipo en el que estamos trabajando es capaz de conectarse a internet, aunque no es estrictamente necesario realizarlo en este momento. Para ello podemos hacer uso de las funciones de comprobación de la conexión.

Otra de las operaciones previas puede ser el marcado del módem, (a través de InternetAttemptConnect, InternetAutodial, etc.), siempre y cuando vayamos a utilizar este tipo de conexión.

Y por último, podemos hacer uso de las funciones InternetAttemptConnect e InternetGoOnline, que se encargará de hacer una comprobación de la bandera "Trabajar sin conexión", para informar al usuario y desactivarla cuando lo crea conveniente.

Todas estas funciones ya las explicamos en profundidad durante nuestro artículo anterior.

El primer paso obligado dentro de Wininet es abrir una instancia del API. Esta apertura de instancia, lo que hace es crearnos un objeto que representará a la aplicación que hace uso de Wininet, identificada por un descriptor. Este objeto funcionará como descriptor raíz, a partir del cual iremos creando otros descriptores (por ejemplo: de conexión, de petición, etc.).

Dentro del API Wininet, cualquier descriptor que creemos será de tipo HINTERNET. Este tipo de dato nos obliga a que estos descriptores sean utilizados solamente con las funciones propias del API Wininet, por lo que no podremos utilizarlos como parámetros de las funciones básicas del API Win32, como CloseHandle, DuplicateHandle, etc. Ni que decir tiene que al contrario tampoco será posible: no podemos crear un descriptor con CreateFile y utilizarlo en una función de Wininet como InternetReadFile.

La función para la apertura del API es InternetOpen, y la situación más normal es que sea llamada una única vez por una aplicación, aunque si queremos definir distintos modos de comportamiento en la conexión (por ejemplo, acceso a través de distintos servidores proxy), debemos llamar a esta función una vez por cada tipo de comportamiento que queramos utilizar.

Vamos a ver cómo se llama a la función InternetOpen:

    HINTERNET InternetOpen(
                LPCTSTR  lpszAplicación,
                DWORD    dwTipoAcceso,
                LPCTSTR  lpszProxy,
                LPCTSTR  lpszExcepciónProxy,
                DWORD    dwOpciones
            );

Los parámetros son los siguientes:

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.

Una vez que hemos enviado una petición a través de la red, ya sea con el método directo o detallado, será procesada por el servidor HTTP que devolverá una respuesta al cliente. Esta respuesta, como ya hemos visto, se compone de una cabecera y los datos que hemos pedido en la petición. A través de Wininet, podemos acceder tanto a los datos de cabecera (que nos proporcionan información sobre el recurso), como al recurso en sí.

Wininet mantiene internamente la estructura de la cabecera retornada, y nos permite acceder a ella a través de una función: HttpQueryInfo.

Esta función nos facilita la lectura de datos de la cabecera, indicando el atributo del cual queremos obtener el dato.

La sintaxis es la siguiente:

    BOOL HttpQueryInfo( 
                 HINTERNET hPetición, 
                 DWORD     dwInformación, 
                 LPVOID    lpBuffer, 
                 LPDWORD   lpdwLongitudBuffer, 
                 LPDWORD   lpdwIndice
             );

Los servidores web comerciales (como Apache, Internet Information Server, etc.) son programas muy completos que permiten gestionar todos los aspectos involucrados en las peticiones HTTP. Uno de los puntos más críticos es la disponibilidad de datos, ya que en un servidor web, lo más normal es que multitud de usuarios estén accediendo a los mismos recursos, y muy posiblemente en el mismo momento.

Para optimizar al máximo estas operaciones, los servidores web cuentan con un caché en el que van situando los datos que pueden ser descargados posteriormente. Por ejemplo, si el servidor recibe una petición HEAD (para recuperar los datos de cabecera de un archivo), lo más probable es que posteriormente se acceda al recurso, así que lo prepara para comenzar a leerse. Del mismo modo, si comenzamos a leer datos de un recurso, el servidor web intentará mantener en el caché aquellos datos que todavía no hemos leído, para que estén disponibles en el momento en que los necesitemos.

Desde el API Wininet podemos consultar qué datos están disponibles para que los leamos desde nuestro cliente HTTP, o bien forzar al servidor a que disponga un bloque de datos para que esté listo para ser leído.

Todo ello lo podemos hacer a través de InternetQueryDataAvailable. Esta función nos retorna el número de bytes disponibles para que leamos en una operación posterior.

Si el servidor no tiene ningún byte disponible, la función fuerza a que se prepare un bloque de datos, y no retornará hasta que esto haya ocurrido.

Un comportamiento especial de esta función se da cuando el recurso se encuentra en el caché y hemos permitido que se lea de él. La función nos retornará siempre el tamaño completo del recurso, ya que al estar en un archivo local, tendremos disponibles todos los datos. Para este caso, podremos leer el recurso con una sola operación e lectura.

La sintaxis es la siguiente:

    BOOL InternetQueryDataAvailable( 
                 HINTERNET hPetición, 
                 LPDWORD   lpdwBytesDisponibles, 
                 DWORD     dwOpciones, 
                 DWORD     dwContexto
             );

• hPetición: un descriptor de petición, obtenido a través de la función InternetOpenUrl (o HttpOpenRequest, utilizando el método detallado, aunque no lo hayamos explicado).

• lpdwBytesDisponibles: un puntero a un valor de 32 bits en el que se almacenará el número de bytes que tiene el servidor disponibles para la lectura.

• dwOpciones: actualmente no hay ninguna opción, así que este valor debe ser 0.

• dwContexto: también debe ser 0.

La función retorna TRUE o FALSE dependiendo del éxito. En caso de error, se puede llamar a la función GetLastError para averiguar el código de error. Si este código es ERROR_NO_MORE_FILES, significará que no se han podido preparar los datos ya que el recurso pedido no existe.

Cuando accedemos a un recurso en internet, lo realmente importante para nosotros es la información que nos proporciona ese recurso, ya sea una página web, un archivo de texto, una imagen o un video, etc.

Para ello, contamos con algunas funciones, muy parecidas a las de lectura/escritura de ficheros, para el acceso a recursos a través de internet.

Utilizando el método directo (el único que conocemos por ahora), solo podemos realizar lecturas de archivos y nunca modificar un dato a través del protocolo HTTP. En el próximo artículo veremos cómo se utiliza el método detallado y cómo utilizar las funciones de escritura de ficheros.

Para leer un recurso remoto, debemos hacer uso de la función InternetReadFile. Esta función se comporta igual que cualquier función de lectura de ficheros, es decir: de un modo secuencial. Una vez leídos los primeros 10 bytes del fichero, la siguiente operación de lectura comenzará a partir del byte 11, así hasta llegar al final.

La sintaxis es la siguiente:

    BOOL InternetReadFile( 
                HINTERNET hPetición, 
                LPVOID    lpBuffer, 
                DWORD     dwTamañoLeer, 
                LPDWORD   lpdwTamañoLeído
            );

• hPetición: un descriptor de petición, obtenido a través de la función InternetOpenUrl (o HttpOpenRequest, utilizando el método detallado, aunque no lo hayamos explicado). Esta petición debe ser obligatoriamente de tipo GET.

• lpBuffer: es un puntero a una zona de memoria donde se copiarán los bytes leídos. El espacio disponible de este buffer debe ser, al menos, de "dwTamañoLeer" bytes.

• dwTamañoLeer: número de bytes que debe leer la función, como máximo, el tamaño del bloque de memoria pasado en lpBuffer. Este valor se debe obtener a través de la función InternetQueryDataAvailable, como ya hemos explicado anteriormente, y el bloque de memoria "lpBuffer" debe reservarse también acorde a este valor.

• dwTamañoLeído: un puntero a una variable (que se pasará a 0) donde se copiará el número de bytes leídos. Normalmente, debemos leer dentro de un bucle hasta que la función copie el valor 0 en este parámetro, para indicar que ya no hay más que leer.

La función retorna TRUE o FALSE. En caso de error, se puede utilizar la función GetLastError para retornar el código de error. Si GetLastError retorna ERROR_INTERNET_EXTENDED_ERROR, debemos llamar a la función InternetGetLastResponseInfo, para que nos retorne el código y la descripción del último mensaje de error recibido desde el servidor. Esta función tiene la siguiente sintaxis:

    BOOL InternetGetLastResponseInfo( 
                   LPDWORD lpdwError, 
                   LPTSTR  lpszDescripción, 
                   LPDWORD lpdwLongitudDescripción 
               );

El uso es sencillo: basta con pasar un puntero a un valor de 32 bits, donde se copiará el código de error, y un puntero a una cadena, donde se copiará la descripción del error.

A partir de IE 4.0, Wininet proporciona una función extendida llamada InternetReadFileEx. El principal uso que se le da es leer el recurso completo, junto con las cabeceras, en una sola llamada a la función.

Como hemos dicho antes, la lectura de fichero de internet es muy parecida a los ficheros locales, ya que internamente se mantiene un puntero que nos indica donde se debe realizar la próxima lectura.

Este puntero, es desplazable por el programación a través de la función InternetSetFilePointer.

La sintaxis es la siguiente:

    DWORD InternetSetFilePointer( 
                   HINTERNET hRecurso, 
                   LONG      lDesplazamiento, 
                   PVOID     pReservado, 
                   DWORD     dwInicio, 
                   DWORD     dwContexto
               );

• hPetición: un descriptor de petición, obtenido a través de la función InternetOpenUrl (o HttpOpenRequest utilizando el método detallado, aunque no lo hayamos explicado). Esta petición debe ser de tipo GET. Además, para utilizar esta función, el descriptor no ha podido crearse con INTERNET_FLAG_DONT_CACHE o INTERNET_FLAG_NO_CACHE_WRITE.

• lpDesplazamiento: número de bytes a desplazar el puntero. Se pueden utilizar tanto valores positivos como negativos.

• lpReservado: debe ser NULL.

• dwInicio: define el origen del movimiento, a partir del cual se desplazará el puntero. Se puede indicar uno de los siguientes valores:

  • FILE_BEGIN: se desplaza "lDesplazamiento" bytes desde el inicio del archivo.
  • FILE_CURRENT: se desplaza "lDesplazamiento" bytes desde la posición actual.
  • FILE_END: se desplaza "lDesplazamiento" bytes desde el final del archivo. Este método fallará si el servidor no es capaz de averiguar la longitud del archivo.

• dwContexto: está reservado para el futuro. Debe pasarse siempre 0.

La función retorna la posición actual, si tiene éxito, o -1 si ha ocurrido un error. Hay que tener en cuenta que la función no puede usarse si hemos alcanzado el final del fichero con repetidas lecturas a través de InternetReadFile.

Y como todos os podréis imaginar, falta la operación obligada: el cierre de descriptores y liberación de memoria.

Y esto es todo, por ahora. Hemos podido ver cómo utilizar el protocolo HTTP desde el API Wininet, aunque sólo a través del método directo.

Como el tema puede resultar algo laborioso (aunque no complicado), he incluído algún ejemplo para aquellos que queráis estudiar el código.

C++Builder 5 Se trata de una pequeña aplicación que nos permite realizar una descarga utilizando el método directo, y además modificar las opciones de descarga a través de distintas banderas. Podéis jugar con ella para ver cómo se comporta la función y ver los resultados obtenidos. Fuentes en ZIP