Arquitecturas Distribuidas
Anuncio
Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 13 Formularios HTML z <html> <!-- Ejemplo 20 --> 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). Arquitecturas Distribuidas 14 Formularios HTML <html> <!-- Ejemplo 20 --> <head> <title>Titulo de la pagina</title> </head> <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> Curso 2008/2009 Arquitecturas Distribuidas 15 Formularios HTML <html> <!-- Ejemplo 21 --> z <head> <title>Titulo de la pagina</title> </head> <body> Formulario para seleccionar parametros para enviar al servidor. <form action=“procesar.cgi” method=“GET”> 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> Arquitecturas Distribuidas 16 Formularios HTML <html> <!-- Ejemplo 21 --> <head> <title>Titulo de la pagina</title> </head> <body> Formulario para seleccionar parametros para enviar al servidor. <form action=“procesar.cgi” method=“GET”> 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 18 Formularios HTML <html> <!-- Ejemplo 21 --> z Al <head> <title>Titulo de la pagina</title> </head> <body> Formulario para seleccionar parametros para enviar al servidor. <form action=“procesar.cgi” method=“GET”> 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 26 CGI 1. El servidor recibe una solicitud Servidor WWW CLIENTE HTTP Curso 2008/2009 Servidor HTTP CGI Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 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 Arquitecturas Distribuidas 39
