u
UD 5 . Servicio Web.
Protocolo HTTP
1
u Índice
1. Introducción
2. URL
3. Características generales
4. Mensajes HTTP
5. Formularios
6. Cookies. Mantenimiento de sesiones.
7. Proxy Web
2
u Índice
1. Introducción
2. URL
3. Características generales
4. Mensajes HTTP
5. Formularios
6. Cookies. Mantenimiento de sesiones.
7. Proxy Web
3
u Introducción. Web y HTTP. Ejemplo HTML
Presentación …
} Una página web está formada por objetos
} un objeto puede ser un fichero HTML, imagen JPEG, applet
Java, etc.…
} una página web consiste en un fichero HTML base que
incluye varias referencias a objetos
} cada objeto es direccionable a través de una URL, por ejemplo:
www.someschool.edu/someDept/pic.gif
nombre del host ruta al fichero
4
u Introducción. Web y HTTP. Ejemplo HTML
<html>
<head>
<h1> Ejemplo html </h1>
<link rel="stylesheet" type="text/css"
href=“http://www.ejemplo.com/css/estilos.css"/>
</head>
<body>
<img src=“http://www.ejemplo.com/img_girl.jpg" width=
"500" height="600">
</body>
</html>
5
u Introducción. Web y HTTP. Ejemplo HTML
1. El cliente descarga el HTML.
2. El cliente descarga el objeto: /css/estilos.css
3. El cliente descarga el objeto: img_girl.jpg
4. El cliente muestra la página web al usuario.
6
u Índice
1. Introducción
2. URL
3. Características generales
4. Mensajes HTTP
5. Formularios
6. Cookies. Mantenimiento de sesiones.
7. Proxy Web
7
u URL (Uniform Resource Locator)
http://www.someschool.edu/someDept/pic.gif
nombre del ruta al fichero
servidor web
nombre del
fichero
Protocolo a utilizar para recuperar el
recurso indicado. Otro ejemplo sería:
ftp://www.someschool.edu
mailto:
[email protected] 8
u URL (Uniform Resource Locator)
http://www.google.es
protocolo nombre del
servidor web
Cuando habitualmente accedemos a cualquier web e
indicamos la URL que conocemos, no incluye la ruta hacia
ningún recurso. ¿por qué?
9
u URL (Uniform Resource Locator)
http://www.google.es
protocolo nombre del
servidor web
Cuando habitualmente accedemos a cualquier web e
indicamos la URL que conocemos, no incluye la ruta hacia
ningún recurso. ¿por qué?
http://www.google.es/index.html
Si el servidor no encuentra la ruta hacia uno de los recursos asume que deseas
descargar el fichero index.html.
Salvo que cambiemos esta configuración en el servidor, la página principal de
nuestra web siempre tendrá que tener este nombre
10
u Índice
1. Introducción
2. URL
3. Características generales
4. Mensajes HTTP
5. Formularios
6. Cookies. Mantenimiento de sesiones.
7. Proxy Web
11
u Características generales
HTTP: HypertextTransfer
Protocol
} Protocolo de capa de
aplicaciónWeb PC running
} modelo cliente/servidor Firefox browser
} cliente: navegador que
solicita, recibe (usando el
protocolo HTTP) y
“muestra” los objetosWeb server
running
} servidor: Servidor Web que Apache Web
envía (usando HTTP) server
objetos en respuesta a
solicitudes
iPhone running
Safari browser
12
u
Características generales
usaTCP: HTTP es “sin estado”
} cliente inicia conexiónTCP } el servidor no mantiene
información sobre
con el servidor (puerto peticiones de cliente
80). anteriores.
} servidor acepta la conexión
TCP desde el cliente.
} Los mensajes HTTP (mensajes
de protocolo de la capa de
aplicación) se intercambian
entre el navegador (cliente
HTTP) y servidorWeb.
} se cierra la conexiónTCP.
13
u
Características generales
HTTP no-persistentes HTTP persistentes
} un objeto es enviado sobre } servidor mantiene la
la conexión TCP conexión abierta después
} entonces se cierra la después de enviar la
conexión respuesta
} los siguientes mensajes entre
} descargar multiples objetos
el mismo cliente y servidor
requiere establecer múltiples se envían sobre la conexión
conexiones TCP abierta
} sobre una única conexión
TCP pueden enviarse
varios objetos entre
cliente y servidor
14
u HTTP no-persistente
sopongamos que el usuario introduce la URL:
www.someSchool.edu/someDepartment/home.index (contiene texto y referencias
a 10 imágenes jpeg)
1a. cliente HTTP inicia la conexiónTCP
con el (proceso) servidor HTTP con 1b. servidor HTTP está esperando
nombre www.someSchool.edu, en conexiones TCP al puerto 80, y
puerto 80 “acepta” la conexión notificando al
cliente
2. cliente HTTP envía un mensaje de
solicitud HTTP (incluyendo la
ubicación del recurso URN). En 3. servidor HTTP recibe el mensaje
este ejemplo indicia: de solicitud, y crea un mensaje de
someDepartment/home.index respuesta que incluye el objeto
solicitado, y envía el mensaje a
través del socket
time
15
u HTTP no-persistente (cont.)
4. Servidor HTTP cierra la conexión
TCP.
5. cliente HTTP recibe el mensaje de
respuesta incluyendo el fichero
html y lo muestra. Al analizar el
fichero encuentra 10 referencias a
time objetos JPEG
6. Los pasos 1-5 se repiten para cada
uno de los 10 objetos
16
u
HTTP persistente
1. Se establece una única conexión TCP.
2. El cliente solicita la página principal:
index.html
3. Obtiene dicha página y encuentra en ella
referencias a otros recursos
4. Pide los nuevos recursos al servidor en
paralelo. Esto quiere decir que NO espera a
recibir el primero para solicitar el segundo,
sino que se piden seguidamente.
5. Responde a las solicitudes de los distintos
recursos.
6. La conexión queda abierta para futuras
peticiones.
17
u HTTP persistente vs HTTP persistente
HTTP no-persistente, problemas: HTTP persistente, desventajas:
} sobrecarga del SO para cada } Conexiones que pueden quedar
conexiónTCP abiertas y que no se utilizarán para más
peticiones.
HTTP no-persistente, ventajas :
} los navegadores suelen abrir
conexiones TCP simultaneas para HTTP persistente, ventajas:
solicitar varios objetos direccionados } el navegador envía la petición de
desde la misma página web. objeto tan pronto como encuentra
la referencia, sin tener que esperar
la confirmación del establecimiento
de conexión.
18
u Índice
1. Introducción
2. URL
3. Características generales
4. Mensajes HTTP
5. Formularios
6. Cookies. Mantenimiento de sesiones.
7. Proxy Web
19
u Mensajes HTTP
§ El protocolo HTTP
diferencia dos tipos de
mensajes:
§ Solicitudes: el cliente PC running
pide al servidor un objeto, Firefox browser
indicando la ruta al objeto
(ruta en la que el servidor
lo almacena). HTTP
Request.
server
§ Respuestas: el servidor running
responde al cliente con el Apache Web
objeto solicitado, puede server
ser un fichero HTML, CSS,
imagen, video, etc. HTTP iPhone running
Response. Safari browser
20
u Mensajes HTTP
Servidor
PC pccomponentes
get fichero.html
200 OK
<html> … </html>
get estilos.css
200 OK
css
get banner.jpg
200 OK
jpg
… 21
u Mensajes HTTP
§ En primer lugar el cliente siempre descargar el html de la
página web a mostrar.
§ En el html encontrará referencias a otros objetos: hojas de
estilos, código javascript, imágenes, etc. que componen la
página web a mostar. Uno por uno irá solicitando todos los
objetos.
22
u Mensajes HTTP. Mensaje de solicitud.
} HTTP mensaje de solicitud:
1. Comando GET, POST, etc. que indica la acción solicitada.
2. URL al objeto sobre el que se debe aplicar la acción indicada.
3. Líneas de cabecera.
4. Retorno de carro que marca el final del mensaje.
1 2
ruta al objeto
comandos GET,
POST, etc. GET /pantallas.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
3 líneas de Accept-Language: en-us,en;q=0.5\r\n
cabecera Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
4 Connection: keep-alive\r\n
retorno de carro. \r\n
23
HTTP mensaje de solicitud: formato
u
general
method sp URL sp version cr lf línea de petición
header field name value cr lf
líneas de
~ ~ cabecera
header field name value cr lf
cr lf
~ entity body ~ cuerpo
24
u
Tipos de métodos
} GET: es utilizado únicamente para consultar información al servidor,
muy parecidos a realizar un SELECT a la base de datos.
} POST: Es utilizado para solicitar la creación de un nuevo registro, es
decir, algo que no existía previamente, es decir, es equivalente a
realizar un INSERT en la base de datos.
} PUT: se utiliza para actualizar por completo un registro existente, es
decir, es parecido a realizar un UPDATE a la base de datos.
} HEAD: pide una respuesta idéntica a la que correspondería a una
petición GET, pero en la respuesta no se devuelve el cuerpo. Esto es
útil para poder recuperar los metadatos de los encabezados de
respuesta, sin tener que transportar todo el contenido.
} DELETE: se utiliza para eliminar un registro existente, es similar a
DELETE a la base de datos.
25
u
Tipos de métodos
HTTP/1.0: HTTP/1.1:
} GET } GET, POST,HEAD
} POST } PUT
} HEAD } carga fichero incluído en el
} solicita al servidor dejar el cuerpo del mensaje en la
objeto solicitado fuera de la carpeta (path) indicado en la
respuesta URL
} DELETE
} elimina el archivo
especificado en la URL
26
u Mensajes HTTP. Mensaje respuesta.
} HTTP mensaje de respuesta:
1. Código de respuesta.
2. Líneas de cabecera.
3. Datos solicitados por el cliente. Enviados en respuesta a una solicitud previa.
Código de
1
respuesta
HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
2 líneas de Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n
cabecera Content-Type: text/html; charset=ISO-8859-1\r\n
\r\n
data data data data data ...
3
Datos html,
imagen,
video, etc.
27
u HTTP código de estado de respuesta
§ El código de estado aparece en la 1ª línea en el mensaje de respuesta
servidor-a-cliente.
Códigos de ejemplo:
200 OK
} solicitud exitosa, el objeto solicitado va a continuación en este mensaje
301 Moved Permanently
} objeto solicitado movido, nueva localización especificada a continuación en
este mensaje (Location:)
400 Bad Request
} mensaje de solicitud no entendido por el servidor
404 Not Found
} documento solicitado no encontrado en este servidor
505 HTTP Version Not Supported
28
u Además: Cabeceras más comunes
§ Campos de cabecera de petición comunes:
§ Campos de cabecera de respuesta comunes:
29
u Índice
1. Introducción
2. URL
3. Características generales
4. Mensajes HTTP
5. Formularios
6. Cookies. Mantenimiento de sesiones.
7. Proxy Web
30
u
Subir una entrada de formulario
método POST:
} páginas web suelen incluir
formularios de entrada
} la entrada es cargada al servidor
en el cuerpo del mensaje
método URL:
} se usa el método GET input
} la entrada es cargada en la
URL de la línea de petición
www.somesite.com/animalsearch?monkeys&banana
31
u Subir una entrada de formulario
método POST:
<form method = “post" action = "insti.php">
<input type = "text" name = "nombre" placeholder="usuario"><br>
<input type = "password" name = "pass" placeholder="contraseña"><br>
<input type = "submit" name = "enviar" value = "Enviar">
</form>
32
u Subir una entrada de formulario
método POST: ruta al código PHP que procesa el formulario
método
Cabecera HTTP
cuerpo del33mensaje
u Subir una entrada de formulario
método GET:
<form method = "get" action = "insti.php"> GET
/insti.php?nombre=alumno&pass=pass_alumno&enviar
<input type = "text" name = "nombre" placeholder="usuario"><br>
<input type = "password" name = "pass" placeholder="contraseña"><br>
<input type = "submit" name = "enviar" value = "Enviar">
</form>
34
u Subir una entrada de formulario
método GET: ruta al código PHP que procesa el formulario
y campos del formulario
método
Cabecera HTTP
este mensaje no contiene cuerpo
35
u Índice
1. Introducción
2. URL
3. Características generales
4. Mensajes HTTP
5. Formularios
6. Cookies. Mantenimiento de sesiones.
7. Proxy Web
36
u
Estado Usuario-servidor: cookies
Muchos sitios Web usan ejemplo:
cookies } Susan siempre accede a
cuatro componentes: Internet desde su PC
1) línea de cabecera cookie en
} visita un sitio específico de e-
mensaje de respuesta HTTP
comercio por privera vez
2) línea de cabecera cookie en
el próximo mensaje de } cuando la solicitud inicial HTTP
solicitud HTTP llega al servidor, este crea:
3) fichero de cookies } ID único
mantenido por el equipo
de usuario y manejado
por el navegador del
usuario
4) base de datos en el
servidorWeb 37
u Cookies. Mantenimiento de la sesión
Cliente Servidor de
Amazon
1 Base de Espacio de
ebay 8734 GET index.html
datos memoria
Se muestra la página 200 OK <html> … </html> 2
principal de Amazon. 4
3 y contraseña a67fj
POST user y pass solicita usuario
Usuario y contraseña
generará la cookie de sesión si el
Se añade a la
ebay 8734 200 OK <html> … </html> 5 usuario y la contraseña enviados son
base de datos amazon a67fj
de cookies 6 set-cookie: a67fj correctos.
El usuario no presenta de nuevo sus credenciales
7 pero Amazon lo reconoce y sabe que tiene la sesión
GET pag2.html iniciada.
cookie: a67fj Con este dato el servidor recupera los datos del
usuario almacenados en memoria (ej: variables de
8
php)
200 OK <html> … </html> 9
Por cada html, imagen, video, etc. que el usuario descargue del
servidor, deberá de enviar la cookie que almacena
38
u Cookies. Formato
} nombre=valor : asocia a una propiedad un valor específico.
Espacio, coma y punto y coma se deben traducir al código URL.
} value=valor : conjunto de letras y dígitos creado por el servidor
que identifica al cliente de manera única.
} expires=fecha : fecha de caducidad de la cookie.
Formato: weekday, DD-Month-YY HH:MM:SS GMT
Por defecto: al cerrar el navegador.
} domain=ámbito : el cliente identifica con ámbito si debe enviar la
cookie al servidor accedido.
Por defecto: el servidor que genera la cookie.
} path=camino : especifica los recursos a los que se envía la cookie.
Por defecto: el script que genera la cookie.
39
u Cookies. Caducidad.
§ Las cookies tienen una fecha de caducidad à marcada por
el servidor.
§ El cliente recibe la cookie acompañada de una fecha de
caducidad.
§ Llegada la fecha, la cookie es borrada por el navegador del
cliente de la base de datos.
40
u Cookies. Caducidad.
§ ¿Qué ocurre si pasada una semana el mismo cliente vuelve
a acceder a Amazon?
?
Dos posibilidades:
a) Si la cookie ha caducado, el cliente debe volver a escribir su contraseña y
usuario, y recibirá una nueva cookie.
b) Si la cookie no ha caducado la sesión seguirá iniciada, ¿cómo?
41
u Cookies. Caducidad.
§ En el siguiente ejemplo, suponemos que ha transcurrido
una semana y que la cookie no ha caducado (sigue
almacenada en la base de datos):
Cliente Servidor de
Amazon
el usuario no presenta de nuevo sus
1 credenciales pero Amazon lo reconoce.
amazon a67fj GET index.html
2
cookie: a67fj
200 OK 3
42
u Cookies propias y cookies de terceros
§ Cookies propias: creadas y gestionadas por la propia página web.
§ Las cookies técnicas son las necesarias para el correcto funcionamiento de la
página web: mantenimiento de la sesión, recordatorio de los elementos que integran
un carrito de la compra, recordatorio del idioma en el que mostrar la página web, etc.
§ Cookies de terceros: creadas y gestionadas por sitios web externos.
§ Ampliamente usadas para publicidad. Habitualmente las páginas Web incluyen una
referencia hacia un Script creado y gestionado por una agencia de publicidad. El
navegador del cliente descarga y ejecuta el script que le llevará a una comunicación
con el servidor de la agencia de publicidad y cuyo resultado será el almacenamiento
de una cookie creada y gestionada por la agencia de publicidad. Esta comunicación
con la agencia le permite registrar una visita de dicho cliente a la página web en
cuestión.
§ Google Analytics. Las páginas web que quieren recoger estadísticas sobre el
comportamiento de los usuarios en su web incluyen una referencia hacia un fichero
JavaScript de Google que genera un cookie al cliente, creada y gestiona por Google.
A partir de dicha cookie se recoge la información y generan las estadísticas que
después Google muestra al propietario de la web.
43
u Cookies propias y cookies de terceros
Servidor
d ex.html amazon
/in
1. GET
.html bli.js” ri pt>
2. In d ex > </sc
.es/pu
/a gencia
c = “ http:/
sr
< script
3. GET /publi.js
5. ejecuta el script
9. Almacena la cookie
y cada vez que se accede 6. PO 4. publi.js
ST info_u
al servidor de la agencia suario Servidor
se envía esta cookie. + acti agencia
vidad
8. Cookie
visita amazon
7. Guarda la información
del usuario
44
u Cookies propias y cookies de terceros
Servidor
d ex.html periódico
cookie 9. GET /in
. In d ex.html li.js” > </sc
ri pt>
10 cia.es
/pub
p: //agen
s r c = “htt
< script
11. GET /publi.js
15. ejecuta el script Cookie
visita amazon
13. PO 12. publi.js
ST inf
o _usua Servidor
rio + a
ctivid agencia
16. Cookie_2 ad Cookie
visita am
visita periódico
publicid azon
ad
14. Reconoce al
usuario y
le muestra publicidad
con lo que vio el día
anterior 45
u Índice
1. Introducción
2. URL
3. Características generales
4. Mensajes HTTP
5. Formularios
6. Cookies. Mantenimiento de sesiones.
7. Proxy Web
46
u
Caches Web. Proxy Web.
objetivo: satisfacer la petición del cliente sin involucrar al
servidor origen
} usuario configura el
navegador: la Web se accede
proxy
vía la caché server
} el navegador envía todas las client
origin
peticiones HTTP a la caché server
} si el objeto está en caché,
este devuelve el objeto
} si no, caché solitica el
objeto desde el servidor client origin
origen y lo devuelve al server
cliente
47
u Más sobre caché Web
} caché actúa tanto como ¿Por qué cachéWeb?
cliente como servidor } reduce el tiempo de
} servidor para el cliente original respuesta para las solicitudes
} cliente para el servidor original
} reduce el tráfico en el enlace
} normalmente la caché es de acceso a una institución
instalada por ISPs
(universidades, compañías,
ISP residencial, etc.)
48
u
GET condicional
proxy servidor
§ Objetivo: no enviar objetos
si la caché tiene una
versión actualizada HTTP request msg
If-modified-since: <date> Cuando el
§ Busca minimizar el retardo en la objeto no
transmisión. ha sido
§ El proxy, almacena la copia HTTP response modificado
junto a la fecha en la que la HTTP/1.0
recibió. 304 Not Modified
Proxy. Indica al servidor la fecha de
la última copia que él tiene
almacenada: HTTP request msg
If-modified-since: <date> Cuando el
If-modified-since: <date> objeto sí
ha sido
Servidor: larespuesta no HTTP response modificado
contiene el objeto si la copia HTTP/1.0 200 OK
de caché está actualizada: <data>
HTTP/1.0 304 Not Modified 49
