Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Tema10 HTTP
Tema10 HTTP
1. Introducción.
2. Mensajes HTTP.
1. Partes del mensaje.
2. Primera línea del mensaje
3. Cabeceras del mensaje.
4. Cuerpo del mensaje.
3. Elementos Avanzados.
1. Cookies
2. Manejo de sesiones.
3. Autentificación y Autorización del cliente.
4. Seguridad
5. Conexiones persistentes
6. Caché.
ARS - 2007 HTTP 1
1. Introducción.
servidor.
TP
HT
Es un protocolo basado en el t ición
HT
TP Servidor
Pe s ta HTTP
esquema petición/respuesta. e
s pu
Re
El cliente envía un mensaje de
petición y el servidor contesta con Mac ejecutando
un mensaje de respuesta, cuyo Netscape
contenido es función de la
petición hecha por el cliente.
ARS - 2007 HTTP 3
1. Introducción.
1. Introducción.
2. Mensajes.
2. Mensajes HTTP.
2.1 Partes del mensaje
Ejemplo
Ejemplo de petición:
GET /saludo.html HTTP/1.1
Host www.uv.es
Ejemplo de respuesta:
HTTP/1.1 200 OK
Date: Sun, 01 May 2003 12:00:01 GMT
Content-Type: text/html
Content-Length: 45
<HTML>
<BODY> Hola Mundo! </BODY>
</HTML>
2. Mensajes HTTP.
2.2 Primera línea del mensaje
Métodos de envío de los datos
GET: Solicita un documento al servidor.
Se pueden enviar datos en la URL
HEAD: Similar a GET, pero sólo pide las cabeceras HTTP.
Comprobar enlaces
Se pueden consultar información sobre el fichero antes de solicitarlo.
POST: Manda datos al servidor para su procesado.
Similar a GET, pero además envía datos en el cuerpo del mensaje.
La URL corresponde a un página dinámica que trata los datos enviados.
PUT: Almacena el documento enviado en el cuerpo del mensaje.
DELETE: Elimina el documento referenciado en la URL.
TRACE: Rastrea los intermediarios por los que pasa la petición.
OPTIONS: Averigua los métodos que soporta el servidor.
En una caché sólo se guardan las respuestas de las peticiones
realizadas con GET y HEAD (POST no).
ARS - 2007 HTTP 12
2. Mensajes HTTP.
2.2 Primera línea del mensaje
Método GET
Sintaxis:
GET <URL> <VERSION>
Solicita el recurso nombrado en la URL
Recurso estático o dinámico (con o sin parámetros)
Variantes (para reducir el trafico en la red):
GET condicional
Baja el recurso sólo bajo ciertas condiciones
Añadiendo las cabeceras:
If-Modified-Since, If-Match, If-Range, etc.
GET parcial
Baja sólo ciertas partes del recurso
Añadiendo la cabecera:
Range: bytes=...
2. Mensajes HTTP.
2.2 Primera línea del mensaje.
Ejemplos
GET http://www.uv.es/index.html HTTP/1.1
Host: www.uv.es
If-Modified-Since: Fri, 1 Feb 2004 13:53:40 GMT
Sintaxis:
POST <URL> <VERSION>
<CABECERA>
<CRLF>
<CUERPO DEL MENSAJE>
Proporciona datos al recurso nombrado en la URL.
Los datos son enviados en el cuerpo del mensaje.
Códigos de respuesta:
200 OK
204 No Content
201 Created (cabecera location)
2. Mensajes HTTP.
2.2 Primera línea del mensaje.
Ejemplo POST
POST /test.cgi HTTP/1.0
Host: www.teco.edu:8080
User-Agent: Mozilla/4.7 (compatible; MSIE 5.0; Windows 5.0)
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 39
name=Marie&path=%2F&ort=Karlsruhe&submit=Submit+Request
HTTP/1.0 200 OK
Date: Wed, 27 Oct 1999 14:13:43 GMT
Server: Apache/1.2.1
Content-Type: text/html
Content-Length: 380
<html><head>
<title>CGI-Script</title> ...
ARS - 2007 HTTP 16
2. Mensajes HTTP.
2.2 Primera línea del mensaje.
Códigos de estado
1xx: Mensaje informativo. 4xx: Error del cliente
2xx: Exito 400 Bad Request
200 OK 401 Unauthorized
201 Created 403 Forbidden
404 Not Found
202 Accepted
204 No Content
5xx: Error del servidor
500 Internal Server
3xx: Redirección Error
300 Multiple Choice 501 Not Implemented
301 Moved Permanently 502 Bad Gateway
302 Found 503 Service Unavailable
304 Not Modified
2. Mensajes HTTP.
2. Mensajes HTTP.
2.3 Cabeceras del mensaje.
Cabeceras de la petición (I)
Exclusivas de la petición.
Preferencias en la respuesta (HTTP/1.1):
Accept: Tipos MIME aceptados por el navegador.
Accept-Charset: Preferencias en el conjunto de caracteres.
Accept-Encoding: Preferencias en la codificación del contenido.
Accept-Language: Preferencia en el Lenguaje del documento.
Peticiones condicionales (HTTP/1.1):
If-Modified-Since: fecha (tb. HTTP/1.0)
If-Unmodified-Since: fecha
If-Match: etiqueta.
La petición será efectiva si coinciden las etiquetas
If-None-Match: etiqueta.
2. Mensajes HTTP.
2.3 Cabeceras del mensaje.
Ejemplos de petición condicional
HTTP/1.1 200 OK
...
Content-Type: text/html
Content-Length: 50
<CRLF>
El contenido de la página
datos.html
2. Mensajes HTTP.
2.3 Cabeceras del mensaje.
Cabeceras Entidad
Mensajes de solicitud y respuesta
HTTP/1.0
Allow: métodos permitidos para el recurso
Content-Encoding: codificación de la entidad (p.e. compresión)
Content-Encoding: gzip
Content-Length: longitud de la entidad (importante en solicitud)
Content-Type: tipo MIME de la entidad
Content-Type: text/html; charset=iso-latin-1
Expires: fecha tope de validez en la caché
Last-Modified: fecha de la última modificación de la entidad
HTTP/1.1
Content-Language: Lenguaje natural de la entidad.
Content-Location: localización URL alternativa.
2. Mensajes HTTP.
2.4 Cuerpo del mensaje.
Internacionalización del contenido
Cada día aparecen en la web millones de documentos
escritos en cientos de lenguajes.
HTTP da soporte para el transporte y procesado de
documentos en lenguajes y alfabetos distintos.
Los clientes mandan las cabeceras Accept-Charset y
Accept-Language para indicarle al servidor los sistemas de
codificación y lenguajes que el cliente entiende, así como
cuales prefiere:
Accept-Charset: iso-8859-1, utf-8
Accept-Language: es, en
El servidor le indica al cliente el alfabeto y lenguaje utilizado con
el parámetro charset de Content-Type y con la cabecera
Content-Language.
Content-Type: text/html; charset=iso-2022-jp
Content-Language: jp
2. Mensajes HTTP.
2.4 Cuerpo del mensaje.
Ejemplo de respuesta
HTTP/1.1 200 OK <CRLF>
Date: Tue, 23 Jan 2001 12:44:27 GMT <CRLF>
Server: Apache/1.3.9 (Unix) Debian/GNU <CRLF>
Last-Modified: Tue, 23 Jan 2001 12:39:45 GMT <CRLF>
ETag: "19e89f-22-3a6d7b91" <CRLF>
Content-Length: 34 <CRLF>
Content-Type: text/html; charset=iso-8859-1 <CRLF>
<CRLF>
<html>Esto es una prueba</html>
3.1 Cookies
Las cookie son información que el navegador guarda en
memoria o en el disco duro dentro de ficheros texto, a
solicitud del servidor.
Incluyen datos generados por el servidor, o datos introducidos en
un formulario por el usuario, enviados al servidor y reenviados por
éste al cliente.
HTTP es un protocolo sin estados (no almacena el estado
de la sesión entre peticiones sucesivas)
Las cookies pueden usarse para asociar estado.
Proporcionan una manera de conservar cierta información entre
peticiones del cliente.
3. Elementos avanzados.
3.1 Cookies
Usos
Almacenar información importante para el servidor.
Constituyen una potente herramienta empleada por los
servidores Web para almacenar y recuperar información acerca
de sus visitantes.
Ejemplos de uso:
Guarda información de la sesión.
Comercio electrónico.
Carrito de la compra.
Personalización de páginas
Idiomas
Seguimiento de las visitas a un Web
Carteles publicitarios
Almacenamiento del login y password
3. Elementos avanzados.
3.1 Cookies
Cookie enviada por el servidor (I)
Cabecera HTTP: “Set-Cookie”
Cabecera incluida por el servidor en el mensaje de
respuesta, cuando quiere enviar una cookie.
Formato:
“Set-Cookie:”
“nombre=valor”: Nombre de la cookie y valor
“;expires=fecha”: Fecha de caducidad
“;path=camino”: Camino
“;domain=dominio”: Dominio
“;secure”: sólo se transmite sobre canales seguros (HTTPS).
Ejemplo:
Set-Cookie: unnombre=unvalor; expires=Mon, 30-Jan-2001
12:35:23 GMT; path=/dir; domain=mi.dominio.com;
secure
3. Elementos avanzados.
3.1 Cookies
Cookie enviada por el cliente
Cabecera HTTP: “Cookie”.
Enviará todas las cookies en una única cabecera HTTP:
Cookie: nombre1=valor1; nombre2=valor2; ...
Proceso:
Cuando un cliente solicita una URL, buscará en su lista de
cookies aquellas que coincidan con ese dominio y con ese
camino.
Dentro de la cabecera “Cookie”, las cookies se ordenan de más a
menos específica (según camino).
No se consideran las cookies caducadas (de hecho, se eliminan).
3. Elementos avanzados.
3.1 Cookies
Ejemplo
3. Elementos avanzados.
3.2 Sesiones
HTTP es un protocolo sin manejo de estados.
Tras la respuesta, el servidor cierra inmediatamente la conexión
(HTTP/1.0).
Los servidores HTTP responden a cada solicitud del cliente sin
relacionar tal solicitud con alguna solicitud previa o siguiente.
El protocolo HTTP no maneja un estado de cada conexión realizada
por el mismo usuario, sea cual sea la versión HTTP.
No existe el concepto de sesión.
Las sesiones son fundamentales en las aplicaciones
Web. Permiten:
Definir varios estados distintos en la aplicación.
Colocar las solicitudes y respuestas dentro de un contexto más
amplio.
Los clientes y servidores intercambian información sobre el estado
de la aplicación.
ARS - 2007 HTTP 38
3. Elementos avanzados.
3.2 Sesiones
Datos asociados a la sesión.
El servidor almacenará la información necesaria para
llevar el seguimiento de la sesión.
Identificador de la sesión.
Identificador del usuario en sesión.
Tiempo de expiración de la sesión.
Dirección donde se encuentra localizado el cliente.
Variables asociadas a la sesión.
Otras variables temporales.
Por la misma naturaleza del HTTP es imposible asegurar
la existencia o la ausencia de una sesión.
Establecer un proceso que revise periódicamente los tiempos de
expiración de cada proceso.
Eliminar los datos asociados a la sesión si ya excedió el tiempo.
3. Elementos avanzados.
3.2 Sesiones
Mecanismos.
Se deben establecer mecanismos ajenos al protocolo
HTTP para llevar el control de la sesión.
A través de Cookies.
Inflando las direcciones URL.
A partir de controles HTML ocultos.
<INPUT type=“hidden” name=“session” value=“1234”>
A partir de la dirección IP del cliente.
El servidor mantiene la información de la sesión en:
Memoria RAM.
Archivos.
Una base de datos.
Los más utilizados son los tres primeros.
Pocas aplicaciones Web hacen uso exclusivo de un tipo
Generalmente se mezclan, obteniendo las ventajas de cada uno
y tratando de evitar sus desventajas.
3. Elementos avanzados.
3.2 Sesiones
Identificadores de la sesión.
Para que la aplicación Web identifique cada petición
HTTP dentro de una sesión, las peticiones deben
contener un identificador pasado a través de:
Parámetros en la URL (método GET)
Parámetros incluidos en el cuerpo del mensaje (método POST)
Cookie
Esto, entre otras cosas, evita que el usuario deba
autentificarse en cada petición.
Los identificadores de la sesión deben ser únicos y
difíciles de adivinar.
Existe la posibilidad de que agentes externos quieran entrar de
manera fraudulenta al sistema.
Es necesario algún mecanismo que provea identificadores
aleatorios y con un gran periodo de repetición
ARS - 2007 HTTP 42
3. Elementos avanzados.
3.3 Autentificación y autorización
Autentificación del usuario
La manera predeterminada de trabajar de la Web es
anónima.
Lo único que se puede saber con seguridad es el número IP del
cliente (si no hay un proxy por medio).
A veces, debido a cuestiones de personalización o a
políticas de restricción, las aplicaciones Web deben
conocer y verificar la identidad del usuario:
A través de un nombre de usuario y una palabra secreta.
A este proceso de identificación se le conoce como
autentificación.
3. Elementos avanzados.
3.3 Autentificación y autorización
Autorización del usuario
Una vez identificado, se comprueba si el usuario y
palabra clave enviados son válidos, así como sus
restricciones de uso.
La lista de usuarios y sus restricciones de uso se encuentra
normalmente en una base de datos.
A este proceso se le conoce como autorización.
Si la respuesta coincide, el servidor transfiere el
recurso.
3. Elementos avanzados.
3.3 Autentificación y autorización
Procedimiento
Cliente Servidor
(1)
GET /servicios/index.html HTTP/1.1
HTTP/1.1 200 OK
(4) Content-type: text/html
<html> ........
ARS - 2007 HTTP 46
3. Elementos avanzados.
3.3 Autentificación y autorización
Autentificación Basic
3. Elementos avanzados.
3.3 Autentificación y autorización
Autentificación Digest
Alternativa mucho más segura que Basic.
Utiliza algoritmos de 128 bits (MD5) para hallar el
compendio del password.
El servidor responde con el mensaje:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm=".."
nonce="HK6TP4C.."
3. Elementos avanzados.
3.4 Seguridad.
El protocolo HTTPS
HTTPS: protocolo que utiliza SSL (o TSL) para
transportar mensajes HTTP (puerto 443).
SSL asegura que la conexión TCP está cifrada, de forma
que una tercera parte no puede espiar su contenido.
Esta ampliamente implementado
Tanto en los navegadores como en los servidores actuales.
La URL comienza por “https://”.
Aunque la conexión HTTP es sin estado, la información
SSL se puede retener y reutilizar.
Cliente y servidor pueden transmitir nuevos mensajes de forma
segura utilizando la misma conexión SSL.
a) HTTP b) HTTPS
3. Elementos avanzados.
3.4 Seguridad.
El protocolo SSL (II)
Permite:
Al cliente SSL, autentificar la identidad del servidor SSL.
Utilizando técnicas de criptografía de llave pública, comprueba que el
certificado del servidor es válido y ha sido avalado por una autoridad
certificadora (CA).
Al servidor SSL, autentificar la identidad del cliente SSL.
Usando las mismas técnicas.
Establecer una conexión encriptada entre ambas máquinas.
Encriptación asimétrica RSA (clave pública).
Encriptación simétrica.
Proveen un alto grado de confidencialidad.
Asegurar la integridad de los mensajes.
Además, la información encriptada es protegida con un mecanismo
para detectar si ésta fue alterada durante su tránsito por la red.
3. Elementos avanzados.
3.5 Conexiones Persistentes.
Conexiones con HTTP/1.0
Crea y cierra una conexión TCP por cada
petición/respuesta HTTP.
No es del todo cierto
Connection: Keep-Alive
Desventajas:
Se incrementa la carga para múltiples peticiones al mismo
servidor.
Establece una nueva conexión TCP para cada objeto
La conexión TCP tarda relativamente bastante tiempo en
establecerse.
Las conexiones keep-Alive dan problemas
Ventajas:
Es fácil de implementar.
3. Elementos avanzados.
3.5 Conexiones Persistentes.
Comparativa
Transacción 1 Transacción 2 Transacción 3 Transacción 4 HTTP/1.0
Res
Res
Res
Res
2
4
1
Servidor
pues
pues
pues
pues
ción
ción
ción
ción
Peti
Peti
ta 2
ta 4
Peti
Peti
ta 1
ta 3
Tiempo
Res
Res
Res
2
4
3
1
Servidor
ción
ción
ción
ción
pues
pues
pues
pues
Peti
Peti
Peti
Peti
ta 1
ta 2
ta 3
ta 4
Tiempo
Conex. TCP
Cliente
ARS - 2007 HTTP 56
3. Elementos avanzados.
3.5 Conexiones Persistentes.
Problemas.
Manejo de la conexiones:
Se suele limitar la conexión para un número finito de recursos.
Caches y servidores deben mantener sólo un tiempo limitado la
conexión abierta, si está inactiva.
¿Cuánto tiempo?
Las respuestas son servidas en serie, ordenadas de
acuerdo a las peticiones (FIFO)
Problema de bloqueo en la cabeza de la lista.
Recursos de gran tamaño provocan que los siguientes recursos
tarden en servirse, aunque sean de pequeño tamaño.
El problema se agudiza si hay cachés intermedias.
El problema persiste aunque los recursos provengan originalmente de
servidores distintos.
3. Elementos avanzados.
3.6 Cachés
Almacenan respuestas (susceptibles de ser guardadas)
con la intención de reducir el tiempo de respuesta y la
carga de la red.
Necesitan asegurar que los contenidos guardados en la
caché son equivalentes a los almacenados en el servidor.
Dos modelos:
Expiración (consistencia débil)
Reduce las peticiones al servidor.
Validación (consistencia fuerte)
Reduce la cantidad de datos a transmitir.
Es imprescindible (para la caché) que el cliente identifique
al servidor original.
Campo de la cabecera HTTP: Host
no
En caché?
si
no si
Sirve al cliente
(mensaje HTTP)
3. Elementos avanzados.
3.6 Cachés.
Cabeceras HTTP para controlar la caché
Los mecanismos en HTTP 1.0 eran muy pobres.
Pragma, Expires, If-Modified-Since y Last-
Modified
HTTP 1.1 añade mecanismos para permitir a las caches
ser más consistentes con los servidores.
Cache-Control, Age, Etag e If-...
El cliente puede forzar a la caché a que actualice siempre
el objeto:
Pragma: no-cache (HTTP/1.0)
Cache-Control: no-cache (HTTP/1.1)
El servidor puede evitar que la caché guarde el objeto.
Cache-Control: no-store (HTTP/1.1)
3. Elementos avanzados.
3.6 Cachés.
Validación con el servidor
La caché contrasta con el servidor si el contenido del
objeto ha cambiado, antes de descargar dicho recurso.
Utiliza peticiones condicionales:
Basadas en la etiqueta (Etag) del objeto guardado en caché
If-Match: etiqueta (Etag del objeto en la caché)
If-None-Match: etiqueta (idem)
Basadas en la fecha de la última modificación (Last-Modified)
If-Modified-Since: fecha (Last-Modified del objeto en caché)
If-UnModified-Since: fecha (idem)
Un objeto guardado en la caché será actualizado si:
La fecha incluida en If-Modified-Since es posterior a la fecha
de la última modificación del objeto en el servidor origen.
La etiqueta incluida en If-None-Match no coincide con la del
servidor origen.
El servidor puede forzar la validación de la caché:
ARS -2007
Cache-Control: must-revalidate
HTTP 62
3. Elementos avanzados.
3.6 Cachés.
Accesos y validación de caché
3. Elementos avanzados.
3.6 Cachés.
Accesos y validación de caché