Protocolo de Transferencia de Hipertexto HTTP (Junio 2011)

Autor: Marco Antonio Vilca Valencia Universidad Alas Peruanas Filial Juliaca Escuela Acadmico Profesional de INGENIERIA DE SISTEMAS E INFORMATICA
Resumen - es el protocolo usado en cada transaccin de la World Wide Web. HTTP define la sintaxis y la semntica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema peticin-respuesta entre un cliente y un servidor.

I.

INTRODUCCION

HTTP es un protocolo sin estado, es decir, que no guarda ninguna informacin sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es informacin que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la nocin de "sesin", y tambin permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado. II. TRANSACCIONES HTTP Una transaccin HTTP est formada por un encabezado seguido, opcionalmente, por una lnea en blanco y algn dato. El encabezado especificar cosas como la accin requerida del servidor, o el tipo de dato retornado, o el cdigo de estado. El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se enve informacin descriptiva en la transaccin, permitiendo as la autenticacin, cifrado e identificacin de usuario. Un encabezado es un bloque de datos que precede a la informacin propiamente dicha, por lo que muchas veces se hace referencia a l como metadato porque tiene datos sobre los datos. Si se reciben lneas de encabezado del cliente, el servidor las coloca en las variables de ambiente de CGI con el prefijo HTTP_ seguido del nombre del encabezado. Cualquier carcter guin ( - ) del nombre del encabezado se convierte a caracteres "_".

El servidor puede excluir cualquier encabezado que ya est procesado, como Authorization, Content-type y Content-length. El servidor puede elegir excluir alguno o todos los encabezados si incluirlos excede algn lmite del ambiente de sistema. Ejemplos de esto son las variables HTP_ACPT y HTP_R_AEN. HT_AEP'. Los tipos MIME que el cliente aceptar, dado los encabezados HTTP. Otros protocolos quizs necesiten obtener esta informacin de otro lugar. Los elementos de esta lista deben estar separados por una coma, como lo dice la especificacin HTTP: tipo, tipo. HTT_USR_AET. El navegador que utiliza el cliente para realizar la peticin. El formato general para esta variable es: software/versin biblioteca/versin.

El servidor enva al cliente: Un cdigo de estado que indica si la peticin fue correcta o no. Los cdigos de error tpicos indican que el archivo solicitado no se encontr, que la peticin no se realiz de forma correcta o que se requiere autenticacin para acceder al archivo. La informacin propiamente dicha. Como HTTP permite enviar documentos de todo tipo y formato, es ideal para transmitir multimedia, como grficos, audio y video. Esta libertad es una de las mayores ventajas de HTTP. Informacin sobre el objeto que se retorna.

Ten en cuenta que la lista no es una lista completa de los campos de encabezado y que algunos de ellos slo tienen sentido en una direccin.

III. VERSIONES HTTP ha pasado por mltiples versiones del protocolo, muchas de las cuales son compatibles con las anteriores. El RFC 2145 describe el uso de los nmeros de versin de HTTP. El cliente le dice al servidor al principio de la peticin la versin que usa, y el servidor usa la misma o una anterior en su respuesta. 0.9 Obsoleta. Soporta slo un comando, GET, y adems no especifica el nmero de versin HTTP. No soporta cabeceras. Como esta versin no soporta POST, el cliente no puede enviarle mucha informacin al servidor. HTTP/1.0 (mayo de 1996) Esta es la primera revisin del protocolo que especifica su versin en las comunicaciones, y todava se usa ampliamente, sobre todo en servidores proxy. HTTP/1.1 (junio de 1999) Versin actual; las conexiones persistentes estn activadas por defecto y funcionan bien con los proxies. Tambin permite al cliente enviar mltiples peticiones a la vez (pipelining) lo que hace posible eliminar el tiempo de Round-Trip delay por cada peticin. HTTP/1.2 Los primeros borradores de 1995 del documento PEP an Extension Mechanism for HTTP (el cul propone el Protocolo de Extensin de Protocolo, abreviado PEP) los hizo el World Wide Web Consortium y se envi al Internet Engineering Task Force. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de HTTP/1.2.[3] En borradores posteriores, sin embargo, se elimin la referencia a HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, incluye en gran medida a PEP. Se public en febrero de 2000. IV. EJEMPLO DE UN DILOGO HTTP Para obtener un recurso con http://www.example.com/index.html 1. 2. el URL

HTTP/1.1 200 OK Date: Fri, 31 Dec 2003 23:59:59 GMT Content-Type: text/html Content-Length: 1221 <html> <body> <h1>Pgina principal de tuHost</h1> (Contenido) . . . </body> </html> V. MTODOS DE PETICIN

Un pedido HTTP usando telnet. El pedido (request), cabeceras de respuesta (response headers) y el cuerpo de la respuesta (response body) estn resaltados. HTTP define 8 mtodos (algunas veces referido como "verbos") que indica la accin que desea que se efecte sobre el recurso identificado. Lo que este recurso representa, si los datos pre-existentes o datos que se generan de forma dinmica, depende de la aplicacin del servidor. A menudo, el recurso corresponde a un archivo o la salida de un ejecutable que residen en el servidor. HEAD Pide una respuesta idntica a la que correspondera a una peticin GET, pero sin el cuerpo de la respuesta. Esto es til para la recuperacin de meta-informacin escrita en los encabezados de respuesta, sin tener que transportar todo el contenido. GET Pide una representacin del recurso especificado. Por seguridad no debera ser usado por aplicaciones que causen efectos ya que transmite informacin a travs de la URI agregando parmetros a la URL. Ejemplo: GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png Ejemplo con parmetros:

Se abre una conexin al host www.example.com, puerto 80 que es el puerto por defecto para HTTP. Se enva un mensaje en el estilo siguiente:

GET /index.html HTTP/1.1 Host: www.example.com User-Agent: nombre-cliente [Lnea en blanco] La respuesta del servidor est formada por encabezados seguidos del recurso solicitado, en el caso de una pgina web:

/index.php?page=main&lang=es POST Somete los datos a que sean procesados para el recurso identificado. Los datos se incluirn en el cuerpo de la peticin. Esto puede resultar en la creacin de un nuevo recurso o de las actualizaciones de los recursos existentes o ambas cosas. PUT Sube, carga o realiza un upload de un recurso especificado (archivo), es el camino ms eficiente para subir archivos a un servidor, esto es porque en POST utiliza un mensaje multiparte y el mensaje es decodificado por el servidor. En contraste, el mtodo PUT te permite escribir un archivo en una conexin socket establecida con el servidor. La desventaja del mtodo PUT es que los servidores de hosting compartido no lo tienen habilitado. Ejemplo: PUT /path/filename.html HTTP/1.1 DELETE Borra el recurso especificado. TRACE Este mtodo solicita al servidor que enve de vuelta en un mensaje de respuesta, en la seccin del cuerpo de entidad, toda la data que reciba del mensaje de solicitud. Se utiliza con fines de comprobacin y diagnostico. OPTIONS Devuelve los mtodos HTTP que el servidor soporta para un URL especifico.Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante peticin en lugar de un recurso especifico CONNECT VI. CDIGOS DE RESPUESTA

N Descripcin 301 Mudado permanentemente 302 Encontrado 303 Vea otros 304 No modificado 305 Utilice un proxy 307 Redireccin temporal 4xx Error por parte del cliente N Descripcin 400 Solicitud incorrecta 402 Pago requerido 403 Prohibido 404 No encontrado 409 Conflicto 410 Ya no disponible 412 Fall precondicin 5xx Error del servidor N 500 501 502 503 504 505 Descripcin Error interno No implementado Pasarela incorrecta Servicio nodisponible Tiempo de espera de la pasarela agotado Versin de HTTP no soportada VII. CONCLUSION

1xx Mensajes N Descripcin 100 111 Conexin Rechazada

2xx Operacin exitosa N 200 201-203 204 205 206 Descripcin OK Informacin no oficial Sin Contenido Contenido para recargar Contenido parcial

3xx Redirecin