1.2 Capitulo 5 Protocolo HTTP
1.2 Capitulo 5 Protocolo HTTP
1.2 Capitulo 5 Protocolo HTTP
En este proyecto, se establece que los clientes, a travs de la aplicacin instalada en sus terminales, accedan al servicio que le proporciona la transaccin econmica, de alguna forma. Puesto que tanto el servicio como el terminal mvil admiten conexiones HTTP, vamos a usar este protocolo para realizar la comunicacin. Por ello se va a proceder a realizar una descripcin de dicho protocolo. 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/1 est recogida en el RFC 2616. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribucin de informacin como el World Wide Web.
Toda la comunicacin entre los clientes y servidores se realiza a partir de caracteres de 8 bits. De esta forma, se puede transmitir cualquier tipo de documento: texto, binario, etc., respetando su formato original. Permite la transferencia de objetos multimedia. El contenido de cada objeto intercambiado est identificado por su clasificacin MIME.
35
Existen tres verbos bsicos (hay ms, pero por lo general no se utilizan) que un cliente puede utilizar para dialogar con el servidor: GET, para recoger un objeto, POST, para enviar informacin al servidor y HEAD, para solicitar las caractersticas de un objeto (por ejemplo, la fecha de modificacin de un documento HTML). Cada operacin HTTP implica una conexin con el servidor, que es liberada al trmino de la misma. Es decir, en una operacin se puede recoger un nico objeto. En la actualidad se ha mejorado este procedimiento, permitiendo que una misma conexin se mantenga activa durante un cierto periodo de tiempo, de forma que sea utilizada en sucesivas transacciones. Este mecanismo, denominado HTTP Keep Alive, es empleado por la mayora de los clientes y servidores modernos. No mantiene estado. Cada peticin de un cliente a un servidor no es influida por las transacciones anteriores. El servidor trata cada peticin como una operacin totalmente independiente del resto. Cada objeto al que se aplican los verbos del protocolo est identificado a travs de la informacin de situacin del final de la URL.
Cada vez que un cliente realiza una peticin a un servidor, se ejecutan los siguientes pasos: 1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introducindola directamente en el campo Direccin 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 y un conjunto variable de informacin, que incluye datos sobre las capacidades del navegador, datos opcionales para el servidor, etc. 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. Si no se utiliza el modo HTTP Keep Alive, este proceso se repite para cada acceso al servidor HTTP.
2.
3.
4.
5.
6.
36
El dilogo con los servidores HTTP se establece a travs de mensajes formados por lneas de texto, cada una de las cuales contiene los diferentes comandos y opciones del protocolo. Slo existen dos tipos de mensajes, uno para realizar peticiones y otro para devolver la correspondiente respuesta. La estructura general de los dos tipos de mensajes se puede ver en el siguiente esquema:
La primera lnea del mensaje de solicitud contiene el comando que se solicita al servidor HTTP, mientras que en la respuesta contiene el resultado de la operacin que es un cdigo numrico que permite conocer el xito o fracaso de la operacin. Despus aparece, para ambos tipos de mensajes, un conjunto de cabeceras (unas obligatorias y otras opcionales), que condicionan y matizan el funcionamiento del protocolo. La separacin entre cada lnea del mensaje se realiza con un par CR-LF (retorno de carro ms nueva lnea). El final de las cabeceras se indica con una lnea en blanco, tras la cual se pueden incluir los datos transportados por el protocolo, por ejemplo, el documento HTML que devuelve un servidor.
GET, que 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.
37
Este comando puede ir acompaado de una cabecera con los siguientes parmetros: -
Accept: indica los formatos de archivo que puede soportar el cliente. Accept-Charset: indica los conjuntos de caracteres que acepta. Accept-Encoding: el tipo de codificacin que acepta. Accept-Language: el lenguaje en el que se har la respuesta de la cabecera. Authorization: clave para tener acceso a lugares restringidos donde se requiere
nombre de contrasea y el formato de autorizacin empleado.
Connection: especifica las opciones requeridas para una conexin. Date: representa la fecha y la hora a la que se envi el comando. From: campo opcional que incluye la direccin de correo electrnico del
usuario del cliente.
Host: especifica la direccin del host del cliente y el puerto de conexin que ha
empleado.
If-Modified-Since: condicin de que slo se responda a la solicitud si la fecha de ltima modificacin del objeto es superior a la indicada en su parmetro. If-UnModified-Since: slo se responde a la solicitud si la fecha de ltima
modificacin del objeto no ha cambiado a partir de la fecha indicada en su parmetro.
Pragma: para incluir directivas de implementacin. Proxy-Authorization: para identificarse a un Proxy. Referer: contiene la URL de la pgina que le ha dado acceso a la que est
solicitando. Esto puede interesarle a los autores de pginas Web para saber en que lugares existen enlaces de su pgina.
38
HEAD, que es igual que el comando GET, y puede usar las mismas cabeceras, pero este comando le pide al servidor que le enve slo la cabecera como respuesta. 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, que tiene un funcionamiento idntico al comando HEAD, pero adems, este comando enva datos de informacin al servidor, normalmente originaria de un formulario Web para que el servidor los administre o los aada a una base de datos.
En la versin 1.1 se han definido algunos comandos adicionales, que slo estn disponibles en determinadas versiones de servidores HTTP, con motivos eminentemente experimentales, que se pueden utilizar, por ejemplo, para editar las pginas de un servidor Web trabajando en remoto. Cuando el servidor enva la respuesta al cliente, le enva la informacin solicitada y una cabecera con una serie campos, estos campos son: -
Age: tiempo transcurrido desde que se cre la respuesta. Allow: especifica qu comandos puede utilizar el cliente respecto al objeto
pedido, como pueden ser GET o HEAD.
Expires: fecha en la que caducar el objeto adjunto. Last-Modified: fecha de la ltima modificacin del objeto. Location: se usa para redirigir la peticin a otro objeto. Informa sobre la
direccin exacta del objeto al que se ha accedido.
Public: da una lista de los comandos que reconoce el servidor. Retry-After: si no puede ofrecer un objeto provisionalmente, indica la fecha
para que se vuelva a hacer la peticin.
Server: especifica el tipo y versin del servidor. Vary: indica que hay ms de una posible respuesta a la peticin pero solo elige
una.
Warning: especfica informacin adicional sobre el estado de la respuesta. WWW-Autenticate: usado cuando se accede a un lugar restringido, sirve para
informar de las maneras de autentificarse que soporta el objeto del servidor.
39
Hay otros parmetros de informacin de cabeceras, que son vlidos tanto para mensajes del cliente como para respuestas del servidor. Estas cabeceras son: -
Content-Length: longitud en Bytes de los datos enviados. Content-Encoding: especifica el formato en el que estn codificados los datos
enviados.
Date: fecha local de la operacin. Las fechas deben incluir la zona horaria en
que reside el sistema que genera la operacin. Por ejemplo: Sunday, 12- Dec-96 12:21:22 GMT+01. No existe un formato nico en las fechas; incluso es posible encontrar casos en los que no se dispone de la zona horaria correspondiente, con los problemas de sincronizacin que esto produce. Los formatos de fecha a emplear estn recogidos en las RFC 1036 y 1123.
Ante cada transaccin con un servidor HTTP, ste devuelve un cdigo numrico que informa sobre el resultado de la operacin, como primera lnea del mensaje de respuesta. Estos cdigos aparecen en algunos casos en la pantalla del cliente, cuando se produce un error.
1xx: mensajes informativos. 2xx: mensajes asociados con operaciones realizadas correctamente. 3xx: mensajes de redireccin, que informan de operaciones complementarias
que se deben realizar para finalizar la operacin.
4xx: errores del cliente; el requerimiento contiene algn error, o no puede ser
realizado.
5xx: errores del servidor, que no ha podido llevar a cabo una solicitud.
40
Se usa para informar al cliente que la parte inicial de la peticin se ha recibido y no ha sido rechazada por el servidor. El servidor est de acuerdo con el cambio de protocolo expuesto en cabecera Upgrade. Operacin realizada satisfactoriamente. La operacin ha sido realizada correctamente, y como resultado se ha creado un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la respuesta. Este nuevo objeto ya est disponible. Puede ser utilizado en sistemas de edicin de documentos. La operacin ha sido realizada correctamente, y como resultado se ha creado un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la respuesta. El nuevo objeto no est disponible por el momento. En el cuerpo de la respuesta se debe informar sobre la disponibilidad de la informacin. La operacin ha sido aceptada, pero no ha producido ningn resultado de inters. El cliente no deber modificar el documento que est mostrando en este momento. El objeto al que se accede ha sido movido a otro lugar de forma permanente. El servidor proporciona, adems, la nueva URL en la variable Location de la respuesta. Algunos browsers acceden automticamente a la nueva URL. En caso de tener capacidad, el cliente puede actualizar la URL incorrecta. El objeto al que se accede ha sido movido a otro lugar de forma temporal. El servidor proporciona, adems, la nueva URL en la variable Location de la respuesta. Algunos browsers acceden automticamente a la nueva URL. El cliente no debe modificar ninguna de las referencias a la URL errnea. Cuando se hace un GET condicional, y el documento no ha sido modificado, se devuelve este cdigo de estado. La peticin tiene un error de sintaxis y no es entendida por el servidor.
201
Created
202
Accepted
204
No Content
301
Moved Permanently
302
Moved Temporarily
304 400
401
La peticin requiere una autorizacin especial, que normalmente consiste en un nombre y clave que el servidor Unauthorized verificar. El campo WWW-Autenticate informa de los protocolos de autentificacin aceptados para este recurso.
41
Est prohibido el acceso a este recurso. No es posible utilizar una clave para modificar la proteccin. La URL solicitada no existe. El servidor ha tenido un error interno, y no puede continuar con el procesamiento.
Not El servidor no tiene capacidad, por su diseo interno, para Implemented llevar a cabo el requerimiento del cliente. El servidor, que est actuando como Proxy o pasarela, ha Bad Gateway encontrado un error al acceder al recurso que haba solicitado el cliente. Service Unavailable El servidor est actualmente deshabilitado, y no es capaz de atender el requerimiento.
Tabla 5. 1: Lista de cdigos de estado HTTP
502
503
El protocolo HTTP est muy extendido en el mundo de Internet, y cualquier usuario de Internet posee un navegador Web, con el que se podr conectar con el servidor Web implementado sin tener que realizar ninguna otra operacin que solicitar una pgina Web como se hace normalmente. As pues se ha optado por adoptar el protocolo HTTP para la comunicacin entre cliente y servidor.
42