Arquitecturas Distribuidas

Transcripción

TEMA 3. Tecnologías de la web
dinámica
Contenido del tema III
Procesado de información en el servidor.
Tipos de peticiones. CGI
II.
Cookies
III. PHP
IV. Lenguajes de script en el cliente
I.
Curso 2008/2009
2
I. Procesado de información en el servidor:
CGI
1. Justificación y ventajas
1.1. ¿Qué es y cómo se consigue?
1.2. Ventajas de las aplicaciones en el lado del servidor
1.3. Aplicaciones comunes
1.4. Formularios HTML
1.5 Peticiones GET y POST
2. Common Gateway Interface (CGI)
2.1. Modelo CGI
2.2. Contexto de ejecución de la CGI
2.3. Formularios HTML
2.4. Peticiones CGI
2.5. Respuestas CGI
2.6. Problemas de las CGI
Justificación y ventajas
¿Qué es la web dinámica?
z
z
El contenido de la web deja de ser estático
Documentos web que cambian en función de
múltiples factores:
– Información proporcionada por cliente
z
z
Servidores procesan la información y devuelven
una respuesta en formato HTML (y muchas veces
además código para ejecutar en el cliente)
Consecuencia: Internet no es sólo una enorme
BBDD de documentos sino una plataforma de
servicios y aplicaciones
Curso 2008/2009
7
¿Cómo se consigue?
z Mediante
aplicaciones en el lado del
servidor => procesan las peticiones de los
clientes antes de devolver el documento.
z Mediante aplicaciones en el lado cliente =>
mejoran la interactividad y descargan al
servidor de peticiones y procesado simple
Curso 2008/2009
8
Ventajas de aplicaciones
en el lado del servidor
z Soporte
multi-plataforma
– Existen diferencias (en los navegadores) que en ciertos
casos evitan el funcionamiento correcto de los scripts
en el lado del cliente. Esto no ocurre si el script está en
el lado del servidor, ya que se ejecuta
independientemente de la plataforma del cliente.
– Solamente hay que optimizar el código en una
plataforma (la del servidor).
Curso 2008/2009
9
Ventajas de aplicaciones
insertadas en el lado del servidor
z Mayores
opciones para desarrollar
aplicaciones
– Los programas en el lado del servidor no están
limitados por razones de seguridad, por lo que pueden
acceder a archivos y bases de datos.
z Integridad
del código
– Los clientes no tienen acceso directo al código,
ya que no es necesario para que éste se ejecute.
Curso 2008/2009
10
Aplicaciones comunes
z Motores
de búsqueda
z Acceso a remoto a aplicaciones corporativas
y bases de datos.
z Acceso a boletines de noticias
z Cualquier aplicación que se alimente de
datos proporcionados por el usuario.
Curso 2008/2009
11
Algunos problemas a resolver
z ¿Cómo
se procesa la información en el
servidor? ¿Quién la procesa?
z ¿Cómo se envía la información al servidor?
z ¿Cómo se agrupan un conjunto de
peticiones relacionadas?
Curso 2008/2009
12
Formularios HTML
z Son
elementos que permiten al usuario
insertar parámetros que se envían hacia el
servidor.
z La etiqueta para declarar un formulario es
<FORM>.
z El
formulario indica la URL que tiene que
procesar la información que se va a enviar
Curso 2008/2009
13
Formularios HTML
z
<html>

Diferentes elementos pueden ir
insertados en un formulario:
<head>
<title>Titulo de la pagina</title>
</head>
– Elementos de entrada de texto,
<body>
Formulario para seleccionar parametros
para enviar al servidor.
<form action=“procesar.cgi” method=“GET”>
Entrada de texto: <input name="a"
type="text"> <br>
Clave: <input type="password“ name="b"
maxlenght="8"> <br>
Checkbox: <input type="checkbox“
name=“c"> <br>
Oculto: <input type="hidden" value="a">
<br>
</form>
</body>
</html>
<INPUT
Curso 2008/2009
claves, imágenes, archivos,
checkbox, etc.
type=“TEXT|PASSWORD|...”>
z
Es posible también declarar
elementos “ocultos”, que no se
muestran al usuario, pero sí
contienen parámetros que se
envían al servidor.
z
Todos los elementos deben llevar
el atributo “name”, que indicará
como se llama el parámetro (en el
cliente y en el servidor).
14
Formularios HTML
<html>

<head>
</head>
<body>
Entrada de texto: <input name="a"
type="text"> <br>
Clave: <input type="password“ name="b"
maxlenght="8"> <br>
Checkbox: <input type="checkbox“
name=“c"> <br>
Oculto: <input type="hidden" value="a">
<br>
</form>
</body>
</html>
Curso 2008/2009
15
Formularios HTML
<html>

z
<head>
</head>
<body>
Selección: <select name="a">
<option> Primera
<option> Segunda
<option> Tercera
</select> <br> <br>
Área de texto: <textarea> Escriba aqui
varias lineas </textarea>
</form>
</body>
</html>
Curso 2008/2009
Elemento de selección
entre un grupo de
opciones:
<SELECT> (<OPTION>)+
z
Áreas de texto (texto con
más de una línea):
<TEXTAREA>
16
Formularios HTML
<html>

<head>
</head>
<body>
<option> Primera
<option> Segunda
<option> Tercera
</select> <br> <br>
</form>
</body>
</html>
Curso 2008/2009
17
Formularios HTML
z Existen,
además dos elementos <INPUT>
especiales:
– RESET:
–
borra el formulario a su estado original
SUBMIT: presenta un botón para enviar el
formulario.
Curso 2008/2009
18
Formularios HTML
<html>

z Al
<head>
</head>
<body>
<option> Primera
<option> Segunda
<option> Tercera
</select> <br> <br>
</form>
</body>
</html>
Curso 2008/2009
pulsar el
botón de
envío, se
realiza una
petición al
URL indicado
en el atributo
action del
<FORM>.
19
Envío de la información
z
z
z
Puesto que se utiliza el protocolo HTTP, estamos
limitados por su una interfaz: sólo se puede
utilizar alguno de los comandos del protocolo.
Se utilizan dos comandos del protocolo: GET o
POST
Dos tipos diferentes de peticiones, según atributo
method del <FORM>.
– Peticiones GET (método GET de HTTP)
– Peticiones POST (método POST de HTTP)
z
Al pulsar el botón de envío el navegador construye
la petición adecuada
Curso 2008/2009
20
Peticiones GET
z
Peticiones GET: (método GET de HTTP)
z
Los parámetros se le añaden al URL tras un signo de “?” y
están disponibles para la CGI en la variable de entorno
QUERY_STRING.
http://site/cgi?name1=value1&name2=value2&name3=value3
•
Los caracteres especiales son trasladados a otros símbolos: Por
ejemplo, los espacios se traducen a “+”, y los caracteres del
ASCII extendido se envían con el formato %NNN (NNN:
número del código ASCII extendido).
Curso 2008/2009
21
Peticiones POST
– Peticiones POST: (método POST de HTTP)
z
z
z
Los parámetros se envían en el paquete HTTP, tras la línea de
solicitud y las cabeceras. Los parámetros son, por tanto, la
entidad u objeto codificado en la petición.
Como en el método GET, los caracteres especiales se traducen
a sus extensiones ASCII.
Es necesario indicar el tipo de codificación en el <form> con el
atributo enctype
– application/x-www-form-urlencoded . (Por defecto). Similar a
GET. NO PERMITE ENVIAR ARCHIVOS
– multipart/form-data. Separa los parámetros mediante una
marca (boundary) aleatoria. PERMITE ENVIAR ARCHIVOS
Curso 2008/2009
22
GET vs POST (I)
z
Problemas GET
–
z
Problemas POST
–
–
z
GET implica “obtener” información. Operaciones idempotentes
POST implica “realizar” una acción con un “efecto secundario”. Operaciones no
idempotentes
Ejemplos
–
–
z
Rompe la funcionalidad del botón “Atrás” del navegador
El botón actualizar repite la operación
Principios generales
–
–
z
No se puede enviar información binaria (archivos, imágenes, etc.) => necesario el
método POST
Buscar usuarios o contenidos: GET
Registrar usuarios o actualizar un perfil: POST
Lectura: manuales/GetvsPost.pdf
Curso 2008/2009
23
GET vs POST (II)
z Consejos:
– Redirección de la página después de un POST
z Una URL que devuelve un código 302 no se
almacena en el histórico del navegador
z Ej.: redireccionar a una página de “Gracias por
registrarte”
z Si el resultado del POST es un error, no se debe
redireccionar
Curso 2008/2009
24
Common Gateway Interface
(CGI)
CGI
z
z
z
Common Gateway Interface
Procedimiento estándar para comunicar servidores
HTTP y aplicaciones externas para generar
documentos de forma dinámica.
El URL identifica un programa ejecutable
(llamado CGI) que sirve de pasarela hacia la
aplicación externa (el servidor web debe poder
identificarlo como tal con algún criterio).
Curso 2008/2009
26
CGI
1. El servidor recibe una solicitud
Servidor WWW
CLIENTE
HTTP
Curso 2008/2009
Servidor
HTTP CGI
Aplicación
externa
27
CGI
2. Inspeccionando el URL, el servidor reconoce la
solicitud como una CGI, no como un documento
Servidor WWW
CLIENTE
HTTP
Curso 2008/2009
Servidor
HTTP CGI
Aplicación
externa
28
CGI
3. El servidor WWW ejecuta el programa,
enviándole los parámetros de la solicitud
Servidor WWW
CLIENTE
Curso 2008/2009
HTTP
Servidor
HTTP CGI
Aplicación
externa
29
CGI
Servidor WWW
CLIENTE
HTTP
Servidor
HTTP CGI
Aplicación
externa
4. El servidor WWW recoge el resultado de la ejecución del programa, le
añade ciertas cabeceras HTTP, y devuelve la respuesta al cliente.
Curso 2008/2009
30
CGI
Servidor WWW
CLIENTE
HTTP
Servidor
HTTP CGI
Aplicación
externa
5. El cliente recibe la respuesta. El formato de la misma debe ser
interpretable: HTML, TXT, etc.
Curso 2008/2009
31
CGI
z
z
z
CGI especifica como pasar parámetros y ejecutar
las aplicaciones externas
La aplicación externa puede estar programada en
cualquier lenguaje, siempre que éste sea capaz de
aceptar la entrada según especifica CGI, y de crear
una respuesta adecuada.
Lenguajes más habituales: PERL, PYTHON, C,
TCSH, BASH.
Curso 2008/2009
32
Contexto de ejecución con CGI
z El
servidor WWW ejecuta la aplicación
externa estableciendo un contexto especial:
CONTEXTO
CLIENTE
Curso 2008/2009
Servidor WWW
Aplicación
externa
33
Contexto de ejecución de la CGI
z En
el contexto, el servidor WWW, fija unas
variables de entorno:
– CONTENT_LENGTH, CONTENT_TYPE,
REMOTE_HOST, REMOTE_USER,
REQUEST_METHOD, SERVER_NAME,
QUERY_STRING,
GATEWAY_INTERFACE, HTTP_*
Curso 2008/2009
34
Peticiones CGI
z
z
Dos formas diferentes. Depende del método con el
que se envíen los parámetros, GET o POST
Para peticiones GET la variable
QUERY_STRING toma el valor de los
parámetros, tal y como aparecen en la URL.
– La aplicación externa lee el valor de la variable
z
Para peticiones POST los parámetros se pasan por
la entrada estándar (stdin).
– La aplicación externa debe leer la entrada estándar.
Curso 2008/2009
35
Respuestas CGI
z
z
La CGI escribe la respuesta en el stdout. El
servidor la lee, y se la envía al cliente.
Según el tipo de servidor, la CGI debe:
– Servidor NPH (No Parse Header): Escribir la respuesta
completa (incluyendo cabeceras)
– Servidor PH (Parse Headers): Escribir la entidad
respuesta, y pasar al servidor indicaciones sobre cómo
formar las cabeceras.
z
Lo habitual es que el servidor sea tipo NPH.
Curso 2008/2009
36
Respuestas CGI
z
Para servidores NPH, una CGI debe generar la
salida:
(Cabecera_CGI|Cabecera_HTTP)
[LÍNEA EN BLANCO]
[Cuerpo_Entidad]
La cabecera_CGI es una de las siguientes:
–
–
–
Content-type: Obligatoria si existe Cuerpo_Entidad
Location: devuelve un puntero (URL) en lugar de la información
Status: resultado de la operación, si no se incluye el cliente
sobreentiende “200 OK”.
Curso 2008/2009
37
Problemas de las CGI
z
z
z
z
Integración Æ Servlets, SSI, PHP
Portabilidad Æ Servlets, PHP
Seguridad Æ Servlets, PHP
Escalabilidad Æ Servlets, PHP, ASP
– Cada vez que se recibe una petición hay que crear un
nuevo proceso -> Es un proceso computacionalmente
costoso
– Solución: se utilizan lenguajes de procesado integrados
en la implementación del propio servidor (módulos
adicionales). Ej.: Servlets, PHP, ASP
Curso 2008/2009
38
Referencias y bibliografía
z
CGI
–
–
–
http://ait.upct.es/asignaturas/ad/manuales/CGI/cgi.
html Æ Manual sobre uso de CGI
http://ait.upct.es/asignaturas//ad/manuales/CGI/env
.html Æ Documento que discute el entorno de
ejecución de una CGI (en inglés)
http://ait.upct.es/asignaturas/ad/manuales/CGI/esp
ecificacion.html Æ Especificación CGI (en inglés)
Curso 2008/2009
39

Arquitecturas Distribuidas

Transcripción

Documentos relacionados

T T l í d L W b di á i Tema 4. Tecnologías de La Web dinámica

LA COLUMNA TOSCANA