EL PROTOCOLO HTTP El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo protocolo cliente-servidor que articula los intercambios

de informacin entre los clientes Web y los servidores HTTP. La especificacin completa del protocolo HTTP 1/0 est recogida en el RFC 1945. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribucin de informacin como el World Wide Web. Desde el punto de vista de las comunicaciones, est soportado sobre los servicios de conexin TCP/IP, y funciona de la misma forma que el resto de los servicios comunes de los entornos UNIX: un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexin de los clientes Web. Una vez que se establece la conexin, el protocolo TCP se encarga de mantener la comunicacin y garantizar un intercambio de datos libre de errores. HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexin con un servidor y enva un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operacin y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actan; cada objeto Web (documento HTML, fichero multimedia o aplicacin CGI) es conocido por su URL. Etapas de una transaccin HTTP. Para profundizar ms en el funcionamiento de HTTP, veremos primero un caso particular de una transaccin HTTP; en los siguientes apartados se analizarn las diferentes partes de este proceso. Cada vez que un cliente realiza una peticin a un servidor, se ejecutan los siguientes pasos: Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introducindola directamente en el campo Location del cliente Web. El cliente Web descodifica la URL, separando sus diferentes partes. As identifica el protocolo de acceso, la direccin DNS o IP del servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor. Se abre una conexin TCP/IP con el servidor, llamando al puerto TCP correspondiente. Se realiza la peticin. Para ello, se enva el comando necesario (GET, POST, HEAD,), la direccin del objeto requerido (el contenido de la URL que sigue a la direccin del servidor), la versin del protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto variable de informacin, que incluye datos sobre las capacidades del explorador, datos opcionales para el servidor. El servidor devuelve la respuesta al cliente. Consiste en un cdigo de estado y el tipo de dato MIME de la informacin de retorno, seguido de la propia informacin. Se cierra la conexin TCP.

Este proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se recoge un documento HTML en cuyo interior estn insertadas cuatro imgenes, el proceso anterior se repite cinco veces, una para el documento HTML y cuatro para las imgenes.

ESTNDAR HTTP/1.0 El estndar HTTP/1.0 recoge nicamente tres comandos, que representan las operaciones de recepcin y envo de informacin y chequeo de estado: GET Se utiliza para recoger cualquier tipo de informacin del servidor. Se utiliza siempre que se pulsa sobre un enlace o se teclea directamente a una URL. Como resultado, el servidor HTTP enva el documento correspondiente a la URL seleccionada, o bien activa un mdulo CGI, que generar a su vez la informacin de retorno. HEAD Solicita informacin sobre un objeto (fichero): tamao, tipo, fecha de modificacin, etc. Es utilizado por los gestores de cachs de pginas o los servidores Proxy, para conocer cundo es necesario actualizar la copia que se mantiene de un fichero. POST Sirve para enviar informacin al servidor, por ejemplo los datos contenidos en un formulario. El servidor pasar esta informacin a un proceso encargado de su tratamiento (generalmente una aplicacin CGI). La operacin que se realiza con la informacin proporcionada depende de la URL utilizada. Se utiliza, sobre todo, en los formularios. Un cliente Web selecciona automticamente los comandos HTTP necesarios para recoger la informacin requerida por el usuario. As, ante la activacin de un enlace, siempre se ejecuta una operacin GET para recoger el documento correspondiente. El envo del contenido de un formulario utiliza GET o POST, en funcin del atributo de <FORM METHOD="...">. Adems, si el cliente Web tiene un cach de pginas recientemente visitadas, puede utilizar HEAD para comprobar la ltima fecha de modificacin de un fichero, antes de traer una nueva copia del mismo. Posteriormente se han definido algunos comandos adicionales, que slo estn disponibles en determinadas versiones de servidores HTTP, con motivos eminentemente experimentales. La ltima versin de HTTP, denominada 1.1, recoge estas y otras novedades, que se pueden utilizar, por ejemplo, para editar las pginas de un servidor Web trabajando en remoto.

Funcionamiento del protocolo HTTP

El protocolo HTTP es el usado en lo que popularmente se conoce como Web. Se usa tanto para que el navegador pida una pgina a un servidor, como para que ste enve la pgina solicitada al navegador. Est basado en el envo de comandos y respuestas en texto ASCII, si bien cada tipo de contenido enviado (archivo en formato HTML, imgenes en diversos formatos, documentos en formato PDF, etc.) se enviar tal cual est almacenado en el servidor. Es decir, los archivos binarios se envan tal cual, aunque los comandos y las respuestas del protocolo HTTP vayan siempre en texto. En realidad, cuando un navegador conecta con un servidor web remoto no slo le solicita la pgina cuya URL el usuario ha tecleado (o la indicada en el enlace seleccionado con el ratn), sino que le informa de detalles del navegador, de la pgina que solicita, etc. Quizs viendo un ejemplo esto ltimo quede ms claro. A continuacin se muestra una peticin HTTP tpica, de la pgina principal de este sitio:

GET / HTTP/1.1 Host: www.24x7linux.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q= 0.9, text/plain;q=0.8,video/xmng,image/png,image/jpeg,image/gif;q=0.2, text/css,*/*;q=0.1 Accept-Language: es-es, en-us;q=0.66, en;q=0.33 Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: ISO-8859-15, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Connection: keep-alive
El proceso completo es el siguiente. El usuario teclea www.24x7linux en su navegador (el prefijo http:// indica el protocolo que habr de usar el navegador tras conectar con el servidor, que es el protoclo predeterminado). El navegador realiza una consulta DNS para averiguar la direccin IP asociada al nombre www.24x7linux.com, por ejemplo 66.227.74.170. Y entonces intenta establecer una conexin TCP al puerto 80 (el predeterminado para los servidores web). Cuando dicha conexin se ha establecido, el navegador enva la peticin HTTP solicitando la pgina indicada tecleada por el usuario. Puesto que no se indic una pgina en concreto, el navegador asume que se solicita la pgina principal, que se representa como /. Como se ve en el listado anterior, adems se enva informacin adicional. Por ejemplo, se informa del navegador en uso ( User-Agent) y en qu idioma se prefiere visualizar la pgina que se est solicitando ( AcceptLanguage) (esto permite que una web albergue los contenidos en varios idiomas, y se le enva al navegador la versin en el idioma que tenga configurado en sus opciones).

Las cabeceras Accept-Encoding y Accept-Charset y Accept le indican al servidor qu tipos de contenidos el navegador entiende y sabe representar. Por ejemplo, mientras que el navegador usado entiende imgenes PNG (image/png), es muy probable que un navegador en modo texto no, y por lo tanto enviar unas cabeceras acorde con sus capacidades. De hecho, estas y otras cabeceras son personalizables, de manera que podemos forzar que nuestro navegador se identifique como otro, para entrar en esos sitios que nos impiden el acceso por la arbitraria razn de no usar un navegador en concreto. La pareja de cabeceras Keep-Alive y Connection, slo est presente en la versin 1.1 del protocolo HTTP, y permite recibir muchos recursos (pginas HTML, imgenes, etc.) a travs de la conexin TCP recin establecida. En la versin 1.0 del protocolo HTTP era necesario establecer y terminar una conexin TCP por cada recurso, lo que resultaba tremendamente ineficiente. Hasta ahora, el servidor slo sabe que tiene que enviar al navegador remoto la pgina inicial del servidor web asociado a la IP a que se ha conectado. Pero no sera posible tener hospedadas las pginas de varios clientes en el mismo servidor y usando la misma direccin IP ( virtual hosting). Para ello, la versin 1.1 del protocolo HTTP aadi la obligatoriedad de la cabecera Host, que indica al servidor las pginas de qu sitio queremos ver, aunque haya varias asociadas a un servidor web en la misma direccin IP. El servidor recibe todas estas (y posiblemente ms cabeceras, por ejemplo, en el caso de que haya algn proxy intermedio), las interpreta, y devolver al navegador una respuesta estndar HTTP (indicando si la peticin tuvo xito o no), y a continuacn la pgina solicitada. En el caso de la pgina principal implcita (/), el servidor tendr configurada un archivo, normalmente index.html, que enviar en caso de no especificarse una pgina en concreto:

HTTP/1.1 200 OK Date: Sun, 10 Nov 2002 22:50:55 GMT Server: Apache/1.3.26 (Unix) mod_bwlimited/1.0 PHP/4.2.2 mod_log_bytes/0.3 FrontPage/5.0.2.2510 mod_ssl/2.8.9 OpenSSL/0.9.6b Content-Type: text/html Age: 130 Connection: close <-- archivo index.html que contiene la pgina principal del sitio -->
Se ha recortado la respuesta del servidor web a la parte interesante de la misma. Como se ve, en primer lugar el servidor informa del xito de la peticin (200 OK) y de la versin del protocolo que conoce ( HTTP/1.1). Tambin indica la fecha y hora en el servidor ( Date) y la versin y mdulos del servidor web (Server). Lo realmente interesante es la cabecera Content-Type, que le dice al navegador el tipo de contenido que viene a continuacin ( text/html) seguido del contenido propiamente dicho (el archivo index.html en el directorio base del servidor web). Si en lugar de pedir una pgina en formato HTML se solicita un recurso binario, como por ejemplo un archivo grfico, la respuesta ser de la forma siguiente:

HTTP/1.1 200 OK Date: Sun, 10 Nov 2002 23:15:31 GMT Server: Apache/1.3.26 (Unix) mod_bwlimited/1.0 PHP/4.2.2 mod_log_bytes/0.3 FrontPage/5.0.2.2510 mod_ssl/2.8.9 OpenSSL/0.9.6b Last-Modified: Fri, 01 Nov 2002 12:23:38 GMT ETag: "23c32f-171cb-3dc2724a" Accept-Ranges: bytes Content-Length: 94667 Content-Type: image/png Age: 131
Una respuesta como la primera, pero en este caso se indica que a continuacin viene el contenido de un archivo binario en formato PNG, el tamao en octetos del archivo, y la fecha de su ltima modificacin. Esta fecha, y el valor de las etiquetas ETag son usados por los cachs de protocolo HTTP para decidir si almacenar o no en su memoria y disco el recurso al cual se refieren, por considerarlo ms reciente que la copia que ya tenan (en caso de tenerla). Cuando alguien vuelve a solicitar ese mismo recurso y la cach ve la peticin, devuelve al cliente la copia almacenada en su memoria, lo cual acelera la carga del recurso y reduce la carga en los enlaces de la red y en el servidor remoto. Evidentemente el protocolo HTTP es mucho ms amplio que lo visto en este breve artculo, pero espero sirva para saber qu sucede desde que introducimos una URL en nuestro navegador, hasta que vemos el resultado en pantalla. Saber estos detalles es especialmente til a la hora de intentar resolver problemas de navegacin, como por ejemplo los que ha venido sufriendo este sitio durante los ltimos das.