HyperText Transfer Protocol



Documentos relacionados
HyperText Transfer Protocol

HTTP Introducción. Redes de Datos Ing. Marcelo Utard / Ing. Pablo Ronco FACULTAD DE INGENIERIA UNIVERSIDAD DE BUENOS AIRES

INTERCAMBIO DE OBJETOS

Capa de Aplicación (Parte 2 de 2)

Protocolos de WWW. Bibliografía: Redes de Computadores: un enfoque descendente basado en Internet : J.F Kurose y K.W. Ross. GSyC 2007.

Redes de Computadoras Práctica 4: World Wide Web

HTTP. Redes I. Departamento de Sistemas Telemáticos y Computación (GSyC) Noviembre de GSyC HTTP 1

Tema 2 El Servicio Web

CGI. Qué significa CGI?

Ataques Web Automáticos: Identificación, Engaño y Contraataque

DESARROLLO DE APLICACIONES PARA LA WEB II

Funcionamiento de Servicios Web, FTP

Clase 22 Nivel de Aplicación WWW Tema 6.- Nivel de aplicación en Internet

Manual Desarrollador Externo

Redes de Computadores II

PROTOCOLO HTTP. Hypertext Transfer Protocol

Servicio de publicación de información web (HTTP)

Protocolo HTTP Apache. Servicios HTTP. Esteban De La Fuente Rubio L A TEX. Universidad Andrés Bello. 17 jun 2011

Tema 2: Protocolo HTTP.

WEB Y HTTP. HTTP: Hypertext Transfer Protocol [RFC 1945] [RFC 2616] Web Page URL (Uniform/Universal Resource Identifier)

Práctica 1. Uso básico de servicios cliente-servidor

La web (el servicio WWW)

Desarrollo y servicios web

SERVIDOR WEB MULTIPLATAFORMA CON IMPLEMENTACIÓN CGI

Challenge/Response en Windows NT

Taller de Sistemas de Información 1. Desarrollo web

Análisis del Proxy-Cache y Reverse-Proxy

Control de acceso para aplicaciones Web

TEMA 3: La Aplicación World Wide Web

Crear un servidor Web en IIS

MANUAL DE USUARIO MÓDULO Web

5.1 Introducción. 5.2 El protocolo HTTP.

3.1 Introducción a Wireshark

EL MODELO DE ESTRATIFICACIÓN POR CAPAS DE TCP/IP DE INTERNET

Desarrollo y servicios web

Tema 4. II - Cookies. Arquitecturas Distribuidas 11/12

Silex. Microframework y camino fácil de aprender Symfony. PHP Tutorial Screencasts

GUÍA BÁSICA DE USO DEL SISTEMA RED

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN

URL. Después de los dos puntos: se interpreta según el método de acceso. Suele contener direcciones y puntos de acceso en una máquina. Esquema URL.

Laboratorio de Aplicaciones Telemáticas (Curso 2009/2010)

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN

Introducción a las Redes de Computadoras. Obligatorio

Sharpdesk V3.5. Guía de instalación: Edición con clave de producto. Versión 1.0

CÓMO CREAR UNA PÁGINA WEB v.1

Raul Flores FSE Leader

documentos electrónicos enlazados HTML (Hyper-Text Mark up Language) HTTP (Hiper-Text Transfer Protocol)

Seguridad en Aplicaciones Web

Clase 4. Ajax XML. XML Ajax definición Breve explicación de como funciona el HTTP XMLHttpRequest. El XML se creó para que cumpliera varios objetivos.

Resumen del módulo EZ Web Lynx.

Documentación de la API clickline.com

AUTORES: OBREGON CARLA ROMERO MARIA MARACAIBO FEBRERO 2012

ATEL ASESORES C.A IP Multimedia Subsystem Prof. Diógenes Marcano

Tema 4: Diseño e Implementación de la Capa Web

Script de pruebas para generar timbre fiscal digital

SUPERINTENDENCIA DE BANCOS Y SEGUROS DEL ECUADOR

vgestorweb vgestorweb 1/9

Arquitecturas REST (Representa3onal State Transfer)

INTRODUCCION. Tema: Protocolo de la Capa de aplicación. FTP HTTP. Autor: Julio Cesar Morejon Rios

Formularios HTML. Elementos de Programación y Lógica

SISTEMA DE BECAS AL EXTERIOR

Instalación y configuración inicial del sistema SIU-Kolla Versión 3.0.0

RESERVACIONES ONLINE MANUAL DE REFERENCIA

13.2 WORLD WIDE WEB (www)

SISTEMA InfoSGA Manual de Actualización Mensajeros Radio Worldwide C.A Código Postal 1060

Guía de migración a firma HMAC SHA256 Conexión por Redirección

Configuración de Apache

Testing de Seguridad de Aplicaciones Web

GUIA PARA EL USO DE E-BANKING. Transacciones a un solo clic!

GUÍA DE INSTALACIÓN Y USO PISIS CLIENTE

Diseño de páginas web

DIPLOMADO EN SEGURIDAD INFORMATICA

LABORATORIO DE RC: PRÁCTICA 4: IMPLEMENTACIÓN DE UN CLIENTE DE CORREO

Tutorial Servicios Web

MICROSITIOS. Perfiles

Anexo Técnico 005 Servicio de Recepción de Facturas Electrónicas

Implementación y administración de Microsoft Exchange Server 2003

RECUPERAR DATOS DE UN FORMULARIO HTML USANDO PHP. USO DE $_GET. EJEMPLOS Y EJERCICIOS RESUELTOS. (CU00833B)

Desarrollo de sitios web con PHP y MySQL

Cómo ingresar a la Sucursal Electrónica?

CAPITULO 3 MOVILIDAD EN LA NAVEGACIÓN Y ALMACENAMIENTO EN BASES DE DATOS

8. Las VLAN 8.1. Visión general de las VLAN La solución para la comunidad de la universidad es utilizar una tecnología de networking

Guía de uso de Moodle para participantes

Recursos de Aprendizaje

Septiembre 2011 Quito Ecuador

MANUAL PARA EL PROCESO DE VERIFICACION LABORAL PLATAFORMA WEB CERILAPCHILE S. A. V 3.0

La publicación. Pere Barnola Augé P08/93133/01510

Laboratorio 2.6.2: Uso de Wireshark para ver las unidades de datos del protocolo

Manual de referencias para la administración Delegada Webmail UNE / Por: Paula Andrea Torres Toro

Introducción a las Redes de Computadoras

Transcripción:

Qué es HTTP? HTTP significa Hypertext Transfer Protocol. HyperText Transfer Protocol Ing. Carlos A. Barcenilla c.a.barcenilla@ieee.org Es el protocolo de red que se utiliza para transferir los archivos (llamados recursos) que forman parte de la World Wide Web. Ya sean estos archivos HTML, imágenes, sonidos, etc... Normalmente HTTP utiliza a TCP como medio de transporte. Basado en HTTP Made Really Easy http://www.jmarshall.com/easy/http/ 1 2 Qué son los Recursos? Estructura de las Transacciones HTTP HTTP se utiliza para transferir Recursos, no solo archivos. Un recurso es un trozo de información que puede identificarse a través de un URL. La clase más común de recursos son los archivos, pero también pueden ser datos generados dinámicamente. HTTP utiliza el modelo cliente/servidor. Un cliente HTTP abre una conexión hacia un servidor HTTP y envía un mensaje de petición (request message), luego el servidor envía un mensaje de respuesta (response message) el cual contiene el recurso que se solicitado. Luego de enviar la respuesta el servidor cierra la conexión. Por ende el protocolo no mantiene estado (stateless) entre las distintas transacciones de un mismo cliente.

Mensajes HTTP 5 Mensajes HTTP Los mensajes HTTP pueden ser: Solicitudes Respuestas Tanto las solicitudes como las respuestas utilizan el formato genérico de e-mails (RFC-822) Ambos tipos de mensajes consisten de Una línea inicial Cero o más encabezados (headers) Una línea en blanco Un cuerpo del mensaje (opcional, ej. archivo, datos de una consulta). Resumiendo el formato de un mensaje HTTP es: <línea inicial, distinta para solicitudes y respuestas> Encabezado1: valor1 Encabezado2: valor2 <más encabezados> Encabezado N: valor N <línea en blanco> <cuerpo de mensaje opcional, contenidos de un archivo, de una consulta, datos binarios, etc> 6 Mensajes HTTP: Línea inicial (Solicitud) Mensajes HTTP: Línea inicial (Respuesta) La línea inicial de una solicitud tiene tres partes separadas entre sí por un espacio. El método (GET, PUT, POST, OPTIONS, TRACE, DELETE,...) El identificador del recurso (URI). La versión del protocolo HTTP en uso. La línea inicial de una respuesta (llamada línea de estado) tiene tres partes separadas entre sí por un espacio. Versión de HTTP Código de estado Frase explicativa (legible por humanos) s: GET /directorio1/directorio2/index.html HTTP/1.0 GET / HTTP/1.1 s: HTTP/1.0 200 OK HTTP/1.0 404 Not Found

Mensajes HTTP: Códigos de estado 9 Líneas de encabezado El código de estado es un entero de 3 dígitos. 1xx: Informativos 2xx: Éxito 3xx: Redirección 4xx: Error de cliente 5xx: Error de servidor Los más comunes: 200 OK Solicitud exitosa, la respuesta se envía en el cuerpo. 404 Not Found El recurso no existe. 303 See Other El recurso se ha movido a otra URL (Dada en el header Location) 500 Server Error Error no esperado en el servidor. Estas líneas proveen información acerca de la solicitud o respuesta. Cada línea de encabezado consiste de un nombre de campo seguido por un carácter dos puntos : y el valor para ese campo. El orden de los campos no es importante. s: User-Agent: Mozilla/6.0 From: juan@perez.com 10 Líneas de encabezado Cuerpo del mensaje HTTP 1.0 define 16 headers (ninguno es obligatorio). HTTP 1.1 define 46 headers (solo Host: es obligatorio). En las solicitudes suelen incluirse los siguientes: User-Agent: (Identifica al software del cliente y la versión). From: (La dirección de e-mail de quien envía la solicitud). En las respuestas algunos encabezados comunes son: Server: (análogo a User-Agent:, ej. Server: Apache/1.3.14). Last-Modified: (fecha de última modificación del recurso, se utiliza para mantener actualizados los cachés, ej. Last-Modified: Fri, 31 Jan 2000 12:12:12 GMT) Luego de las líneas de encabezado un mensaje HTTP puede contener un cuerpo (body). En las respuestas el cuerpo es la sección en donde se envía el recurso solicitado. En las solicitudes el cuerpo se utiliza para subir datos que ingresó el usuario o para transferir archivos hacia el servidor. Las líneas de encabezado más comunes que definen el cuerpo son: Content-Type: (Da el tipo MIME de los datos del cuerpo, ejemplo: text/html image/gif). Content-Lenght: (Especifica el número de bytes en el cuerpo).

de sesión HTTP 13 El método HEAD El cliente desea obtener http://www.ieee.org/numero/uno.html El cliente establece una conexión TCP al puerto 80 de www.ieee.org y envía la solicitud con el método GET. GET /numero/uno.html HTTP/1.0 User-Agent: MiBrowser/2.0 [línea en blanco] El server responde por la misma conexión con: HTTP/1.0 200 OK Date: Sat, 18 Nov 2000 15:18:02 GMT Content-Lenght: 52 [línea en blanco] <html><body> <h1>mi Archivo HTML</h1> </body></html> Una solicitud con el método HEAD es similar al GET con la diferencia que en este caso la respuesta solo contiene los encabezados y no el cuerpo. Es útil para verificar las características de un recurso sin necesidad de transferirlo. Las respuestas a métodos HEAD nunca contienen cuerpo. 14 El método POST El método POST () Una solicitud POST se utiliza para enviar datos al servidor (por ejemplo para enviar un formulario). El método POST se diferencia del GET pues Hay un bloque de datos que se envía con la solicitud (en el cuerpo de la misma). Hay normalmente headers que describen el cuerpo que se envía (ej. Content-Type y Content-Lenght). El URI que se solicita no es un recurso sino normalmente un script al que se le envían los datos. La respuesta HTTP normalmente es generada dinámicamente. El método POST se usa comunmente para enviar un formulario HTML a un script que se ejecuta en el servidor. En este caso Content-Type toma el valor application/x-www-form-urlencoded y Content-Lenght indica su longitud. (enviar las variables nombre=juan y Apellido=Perez): POST /directorio/script.cgi HTTP/1.0 User-Agent: TuBrowser/1.7 Content-Type: application/x-www-form-urlencoded Content-Length: 26 nombre=juan&apellido=perez

HTTP 1.1 17 HTTP 1.1: Clientes HTTP 1.1 fue definido para atacar nuevas necesidades y solucionar problemas de HTTP 1.0. Las mejoras incluyen: Respuesta más veloz (permite que en una sola conexión se realicen varias transacciones solicitud/respuesta). Ahorro de ancho de banda a través del uso de caché. Respuesta más rápida para páginas generadas automáticamente, permite que una respuesta se envíe aún cuando no se sepa su longitud total (chunked response). Para cumplir con HTTP 1.1 los clientes deben: Incluir el encabezado Host: en cada solicitud. Aceptar respuestas en modo chunk. Soportar conexiones persistentes o incluir el encabezado Connection: close en cada solicitud. Ser capaces de manejar la respuesta 100 Continue. Uso eficiente de las direcciones IP (permite servidores virtuales basados en nombres). 18 HTTP 1.1: Encabezado Host A partir de HTTP 1.1 un server en una dirección IP puede manejar múltiples sitios webs virtuales. Para que ello sea posible cada solicitud debe incluir el encabezado Host. : GET /directorio/archivo.html HTTP/1.1 Host: www.sitio.com [línea en blanco] Host es el único encabezado obligatorio en una solicitud HTTP 1.1. HTTP 1.1: Chunked Transfer-Encoding Si un servidor desea comenzar a enviar la respuesta antes de conocer su longitud total puede hacerlo incluyendo el encabezado Transfer-Encoding: chunked. El cuerpo de un mensaje con esta codificación contiene una serie de trozos (chunks) seguidos con una línea con un 0 (cero), seguido de una serie de footers (iguales a los headers). Cada trozo contiene dos partes: Una línea con el tamaño de ese trozo (en hexadecimal). Los datos en si mismos (al final se agrega CRLF).

HTTP 1.1: Chunked Transfer-Encoding 21 HTTP 1.1: Chunked Transfer-Encoding : Date: Sat, 18 Nov 2000 13:29:14 GMT Content-Type: text/plain Transfer-Encoding: chunked 1b; ignorar lo que va luego del punto y coma Este es un ejemplo de trans 12 ferencia en trozos 0 Footer1: valor1 Footer2: valor2 [línea en blanco] El ejemplo anterior equivale a: Date: Sat, 18 Nov 2000 13:29:14 GMT Content-Type: text/plain Content-Length: 45 Footer1: valor1 Footer2: valor2 Este es un ejemplo de transferencia en trozos 22 HTTP 1.1: Conexiones Persistentes En HTTP 1.1 las conexiones son persistentes por defecto, esto significa que luego de una transacción el servidor no cierra la conexión sino que espera otra solicitud. El cliente puede incluir el encabezado Connection: close en una solicitud para indicar que se luego de enviar la respuesta el servidor debe cerrar la conexión. Un cliente que no soporta conexiones persistentes debe incluir siempre el encabezado Connection: close. HTTP 1.1: El encabezado Date Para implementar cachés HTTP es necesario registrar las fechas y horas de creación/modificación de los recursos (timestamps). Para ello se incluye el encabezado Date. Los servers deben incluir la fecha y hora actual utilizando este encabezado. : Date: Sun, 19 Nov 2000 19:39:22 GMT

HTTP 1.1: If-(un)modified-since 25 Para ahorrar ancho de banda, HTTP 1.1 define los encabezados If-Modified-Since y If-Unmodified-Since. If-Modified-Since Indica que solo se debe enviar el recurso solicitado si ha cambiado luego de la fecha especificada. Se utiliza con el método GET. Si no ha cambiado el servidor responde con 304 Not Modified. : If-Modified-Since: Sun, 12 Dec 1999 21:59:59 GMT If-Unmodified-Since Indica que solo se debe enviar el recurso solicitado si éste no ha cambiado luego de la fecha especificada. Puede usarse con cualquier método. Si el recurso ha cambiado el servidor responde con 412 Precondition Failed. : If-Unmodified-Since: Sun, 12 Dec 1999 21:59:59 GMT GET /Xasx/tnt/private.htm HTTP/1.1 Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Host: ultimateanarchy.com Date: Sat, 18 Nov 2000 20:41:27 GMT Server: Apache/1.3.12 (Unix) mod_bwlimited/0.5 PHP/4.0.2 mod_perl/1.24 mod_log_bytes/0.2 mod_frontpage/3.0.4.3 mod_ssl/2.6.6 OpenSSL/0.9.5a Last-Modified: Sat, 18 Nov 2000 16:36:33 GMT ETag: "22ff8-53e-3a16b011" Accept-Ranges: bytes Content-Length: 1342 Keep-Alive: timeout=15, max=100 <form method=post action="http://www.ezgreen.com/_cgi/subscriber.cgi">... </form> 26 GET /estilos/estilos.css HTTP/1.1 Accept: */* Referer: http://www.datosenlaweb.com/ If-Modified-Since: Mon, 25 Sep 2000 19:49:47 GMT If-None-Match: "8f010-5ba-39cfac5b" User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Host: www.datosenlaweb.com Cookie: PHPSESSID=1191dab4f547c4a02a85143a4c918fd6 HTTP/1.1 304 Not Modified Date: Sat, 18 Nov 2000 19:42:20 GMT Server: Apache/1.3.12 Ben-SSL/1.40 (Unix) PHP/3.0.15 Keep-Alive: timeout=15, max=100 ETag: "8f010-5ba-39cfac5b" GET /images/partners/datosbanner.gif HTTP/1.1 Accept: */* Referer: http://www.datosenlaweb.com/ If-Modified-Since: Wed, 27 Sep 2000 15:37:30 GMT If-None-Match: "09992d89828c01:a14" User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Host: www.decidir.com.ar Cookie: datosusuario=sitio=1 HTTP/1.1 304 Not Modified Server: Microsoft-IIS/4.0 Date: Sat, 18 Nov 2000 20:39:54 GMT ETag: "09992d89828c01:9ed8" Content-Length: 0

29 GET /server/ad/datosenelweb/ros/974579848720? HTTP/1.1 Accept: */* Referer: http://ads.clickexperts.net/hserver/site=dew/area=tei.not.univ.proe/d EW=HOME/LANG=ES/EI=3/ES=4/POS=T/AAMSZ=FULL User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Host: ad-adex3.flycast.com Cookie: atf=1_2521127420 HTTP/1.0 302 Moved Temporarily Server: DWExtension Location: http://crs.clickexperts.net/sites/dew/data54.gif Ad-Reach: EngageMedia GET / HTTP/1.1 Accept: application/vnd.ms-excel, application/msword, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, */* User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) Host: www.datosenlaweb.com Date: Sat, 18 Nov 2000 19:42:18 GMT Server: Apache/1.3.12 Ben-SSL/1.40 (Unix) PHP/3.0.15 X-Powered-By: PHP/3.0.15 Set-Cookie: PHPSESSID=1191dab4f547c4a02a85143a4c918fd6 Keep-Alive: timeout=15, max=100 Transfer-Encoding: chunked ecd <HTML><HEAD... </td> ffb <form...</html> 0 30 HEAD / HTTP/1.0 HTTP/1.0 302 Found Content-Length: 155 Connection: Close Server: GWS/2.0 Date: Mon, 07 Oct 2002 14:04:01 GMT Location: http://www.google.com.ar/ Set-Cookie: PREF=ID=66e653d35b020a90:TM=1033999441:LM=1033999441:S= bgzmipqklm23w25b; expires=sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com GET /docs/ HTTP/1.1 Accept: image/g if, image/x-xbitmap, image/jpeg, image/pjpeg, app licat ion/vnd.ms-excel, applicat ion/vnd.ms-powerpoint, app licat ion/msword, */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: sg.rec.utn.edu.ar HTTP/1.1 302 Found Date: Mon, 07 Oct 2002 14:26:49 GMT Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 X-Powered-By: PHP/4.1.2 Location: php/buscador.php3 Connection: close Transfer-Encoding: chunked 0

(Request) 33 (Response) GET /docs/php/buscador.php3 HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, application/msword, */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: sg.rec.utn.edu.ar Date: Mon, 07 Oct 2002 14:26:49 GMT Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 X-Powered-By: PHP/4.1.2 Set-Cookie: PHPSESSID=35bf915272e201ec63e2adfbbd9322f4; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Connection: close Transfer-Encoding: chunked e0b <html><head>....</ 19a table><hr size="1">.</ 19 center></body></html> 0 34 (Request) GET /docs/images/logohpgif.gif HTTP/1.1 Accept: */* Referer: http://sg.rec.utn.edu.ar/docs/php/buscador.php3 If-Modified-Since: Tue, 18 Jun 2002 20:21:04 GMT If-None-Match: "7e5a-a5d-3d0f9630" User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: sg.rec.utn.edu.ar Cookie: PHPSESSID=35bf915272e201ec63e2adfbbd9322f4 HTTP/1.1 304 Not Modified Date: Mon, 07 Oct 2002 14:26:51 GMT Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 Connection: close ETag: "7e5a-a5d-3d0f9630" GET /docs/php/login.php3?phpsessid=35bf915272e201ec63e2adfbbd9322f4 HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Referer: http://sg.rec.utn.edu.ar/docs/php/buscador.php3 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: sg.rec.utn.edu.ar Cookie: PHPSESSID=35bf915272e201ec63e2adfbbd9322f4

(Response) 37 Date: Mon, 07 Oct 2002 14:26:55 GMT Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 X-Powered-By: PHP/4.1.2 Pragma: no-cache Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Connection: close Transfer-Encoding: chunked 921 <html><head> </html> 0