World Wide Web. Introducción. Móstoles, 3 de marzo de 2004

Transcripción

1 Móstoles, 3 de marzo de 2004 Introducción Desde hace 50 años se ha soñado con una base de datos de conocimientos global, accesible desde cualquier lugar, y que proporcione la información requerida por cada usuario. Vannevar Bush, Este tipo de sistemas permitiría el avance de la ciencia y la educación. La tecnología no estaba a la altura. 1/58

2 Qué es el WWW? El es: Un conjunto de documentos, servicios y recursos de información accesibles a través de Internet cuya ordenación se basa en estructuras de hiperenlaces ( La infraestructura que permite la publicación y consulta de dichos documentos, servicios y recursos a escala mundial. El está revolucionando muchos elementos de la sociedad, como el comercio, la poĺıtica, la literatura, los servicios sociales. 2/58 Hipertexto e Hipermedia Hipertexto: El texto contiene enlaces con otros documentos. Seleccionando estos enlaces con el ratón o teclado se puede acceder a otro documento que a su vez puede ser un hipertexto. Se forma así una red a través de la cual se puede ir obteniendo información según se requiera. Hipermedia: los documentos hipermedia contienen enlaces a otros documentos hipermedia o a otros medios: sonido, imágenes, video, programas (Java). Las propias imágenes pueden tener asociados enlaces a otros elementos. 3/58

3 Historia de servicios de información en Internet Primero fue la Transferencia de ficheros. Después Mail, News. En los 90 llegan los ojeadores (gopher, www) y la navegación. Y En el futuro?: Publicación y compartición de nuevos servicios y recursos. Más cerca de la intuición humana. Comunicaciones móviles 4/58 Historia del WWW ( 1945: Vannevar Bush escribe un artículo acerca de un dispositivo que podría crear y seguir enlaces en documentos en microfichas. 1960s: Doug Engelbart hace un prototipo de online System (NLS) que permite editar hipertextos, correo y otras cosas. Inventa el ratón para este sistema. Ted Nelson inventa el término hipertexto. 1980: Tim Berners-Lee (TBL) escribe un programa de notebook con enlaces entre notas mientras es consultor para el CERN (European Laboratory for Particle Physics). 5/58

4 Historia del WWW 1989: TBL escribe una propuesta de sistema de información basado en hipertexto, y la hace circular en el CERN. Objetivo: construcción de un sistema de difusión de información hipertextual para intercomunicar a los miembros de la comunidad científica de la física de altas energías a través de Internet En principio no se pensó en incluir imágenes, audio o vídeo 1990: TBL construye un prototipo de ojeador y editor en un NeXT cube. Lo llama WorldWideWeb : Desarrollos y popularización. Ojeadores disponibles. 50 servidores. A partir de 1992 las contribuciones de voluntarios de todo el mundo han desarrollado WWW, habiendo explotado en 1993, con la aparición de Mosaic 6/ : CERN permite el libre uso de la tecnología WWW. Marc Andreessen presenta NCSA Mosaic. 1 % trafico en Internet es WWW. 200 servidores. 1994: Creación del WWW Consortium ( 7/58

5 Ya existían herramientas como: Por qué el WWW? gopher: Jerarquía de recursos, no de máquinas navegación independiente de máquinas WAIS (Wide Area Information System): Búsqueda de recursos ftp: Obtención y publicación de recursos Si ya existía la tecnología Por qué WWW? WWW permite, además, enlaces dentro de documentos. 8/58 A Qué podemos acceder desde el WWW? Información servida por Gopher Información servida por WAIS (Wide-Area Information Servers) Información servida por FTP Servicios de Archie Servicios de Veronica Servicios de directorio CSO, X.500, whois Servicio finger Usenet News telnet 9/58

6 A Qué podemos acceder desde el WWW? hytelnet techinfo y texinfo hyper-g Páginas de manual en formato man Documentos hipermedia en formato HTML Applets Java MPEG, audio 10/58 Por qué ha triunfado WWW? Desde el principio se proporcionó acceso a todos los servicios de forma uniforme y transparente (estandarización, cooperación, etc.) Llego en el momento apropiado. Mayor necesidad de acceso a la información por parte de empresas, organizaciones e individuos. Modelo de funcionamiento intuitivo y bien adaptado a las necesidades del ser humano. Facilidad de uso. Aparece Mosaic en el invierno de Efecto de realimentación positiva: Los servidores de información ponen más información en la red porque hay más clientes potenciales, y surgen más clientes potenciales porque hay más información a la que acceder. 11/58

7 Arquitectura del WWW WWW está diseñado siguiendo una arquitectura distribuida cliente-servidor Un cliente de WWW es un programa que envía peticiones de documentos a cualquier servidor de WWW Un servidor de WWW es un programa que, una vez recibida una petición, envía el documento requerido al cliente El cliente puede estar corriendo en una máquina diferente a la del servidor, en otra habitación, país o continente El servidor se encarga del almacenamiento de los documentos El cliente se encarga de la presentación de los documentos 12/58 El Servidor WWW Aceptan conexiones de los clientes y sirven recursos (ficheros reales o virtuales generados por programas). Se basan en TCP/IP para transportar la información. Por convención, esperan las peticiones de los clientes escuchando en el puerto 80 de TCP que está reservado para este servicio (no es estrictamente necesario). En general, no conservan el estado de los clientes (exceptuando el uso de cookies). Diseñados para optimizar las prestaciones Servidores Multithreaded. Granjas de servidores. 13/58

8 El Cliente WWW Recuperan información de los servidores siguiendo las instrucciones de los usuarios. Se basan en TCP/IP para recuperar la información. Se conectan al puerto 80 de los servidores para hacer las peticiones. Diseñados para optimizar la interacción con el usuario Intuitivos. Soportan múltiples formatos de imágenes. Tratan de representar la información de la mejor manera posible. Informaciones especiales(plug-ins, helpers, etc.) 14/58 Interacción cliente-servidor en HTTP El cliente abre una conexión TCP con el servidor. El cliente envía un mensaje de petición. El servidor responde con un mensaje de respuesta. El servidor cierra la conexión TCP. HTTP no mantiene estado (no hay información sobre las conexiones entre una petición y otra). El WWW proporciona un mecanismo común para acceder a diferentes tipos de servicios/documentos a través de un sistema de nombres: Uniform Resource Locator (URL) 15/58

9 Esquema de funcionamiento hojeador Servidor WWW Servidor WWW F. configuracion LOGS Cache Documentos Guion 16/58 Protocolos del WWW El protocolo del nivel de aplicación en el WWW es el HTTP (HyperText Transfer Protocol Su objetivo es la transmisión de recursos (ficheros reales o virtuales). El protocolo especifica qué mensajes puede enviar el cliente al servidor y qué respuestas puede dar el servidor al cliente. Es un protocolo que no conserva el estado entre llamadas Utiliza TCP como protocolo de transporte La versión actual es HTTP 1.0. La siguiente aprobada: HTTP 1.1, y después HTTP- NG 17/58

10 HTTP: funcionamiento básico Cuatro pasos: 1. Establecimiento de conexión: el cliente establece una conexión TCP al puerto 80 del servidor (u otro especificado en la URL) 2. Petición de documento: El cliente envía una ĺınea con un comando, un path/url y la versión del protocolo, en ĺıneas separadas cero o más cabeceras, opcionalmente argumentos de formulario o fichero, y termina con ĺınea en blanco (dos pares de retorno de carro, fin de ĺınea): GET /index.html HTTP/1.0 Accept: text/html Accept: text/plain User-Agent: Lynx/2.4 libwww/2.1.4 Otros comandos: HEAD (devuelve la cabecera del documento), PUT para transferir un fichero al servidor y POST para enviar datos de un formulario al servidor 3. Respuesta del servidor: status line (versión, código de respuesta, frase con razón), en ĺıneas separadas cero o más cabeceras, una ĺınea en blanco, opcionalmente un documento: 18/58 HTTP/1.0 OK 200 Server: NCSA/1.4.2 MIME-version: 1.0 Content-type: text/html Content-length: 110 <html><head> <Title> Documento de HTML de prueba </Title> </Head> <body> El resto del document va aquí </body></html> 4. Cierre de la conexión: Cada elemento de un documento se transfiere con una conexión, por lo que el servidor, el cliente, o ambos, terminan la conexión en este punto. El servidor no guarda estado (stateless) 19/58

11 Formato de los mensajes HTTP Mensajes legibles (compuestos por ĺıneas de texto casi en inglés ): Línea inicial (diferente para peticiones y respuestas), terminada en CRLF. Cero o más ĺıneas de cabecera, cada una terminada en CRLF: Cabecera-X: Valor-X CRLF Línea en blanco (CRLF). Cuerpo del mensaje (opcional). Además de CRLF, deberían tratarse adecuadamente ĺıneas terminadas en LF. 20/58 Formato de las peticiones método sp camino de acceso sp versión cr lf Cabecera-1: sp valor cr lf... Cabecera-N: sp valor cr lf cr lf Cuerpo de la petición (opcional) Formato de las respuestas versión sp código de estado sp descripción cr lf Cabecera-1: sp valor cr lf... Cabecera-N: sp valor cr lf cr lf Cuerpo de la respuesta 21/58

12 Línea inicial (peticiones) Especifica el recurso que se solicita, y qué se quiere de él: Nombre de método (GET, POST, HEAD). Camino de acceso (path) Versión de HTTP (siempre HTTP/x.x). Ejemplo: GET /directorio/otro/fichero.html HTTP/1.0 GET: Pide al servidor que le envíe el recurso especificado. 22/58 Métodos HEAD y POST HEAD: Igual que un GET, pero sólo pide las cabeceras. Se pueden consultar las características sin bajarse el fichero. Muy utilizado para verificar si un documento ha caducado en una caché. POST: Hay datos en el cuerpo (que se suben al servidor). El URI pedido es normalmente el programa que trata los datos enviados. También se pueden enviar datos con un GET (codificándolos en el URL pedido). 23/58

13 Ejemplo (GET, petición) GET /~jgb/test.html HTTP/1.1\r\n Connection: Keep-Alive\r\n User-Agent: Mozilla/4.07 [en] (X11; I; Linux i586; Nav)... Host: gsyc.escet.urjc.es\r\n Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, i... Accept-Encoding: gzip\r\n Accept-Language: en\r\n Accept-Charset: iso ,*,utf-8\r\n \r\n 24/58 Ejemplo (POST, petición) POST /comments.pl HTTP/1.0\r\n From: User-Agent: MegaNavigator/0.0\r\n Content-Type: application/x-www-form-urlencoded\r\n Content-Length: 18\r\n \r\n section=all&rank=10 25/58

14 Proporciona información de estado: Versión de HTTP (siempre HTTP/x.x). Código numérico de estado. Código de estado en inglés. Códigos de estado: 1xx: Mensaje informativo. 2xx: Resultado exitoso. 3xx: Redirección del cliente a otra URL. 4xx: Error en el lado del cliente. 5xx: Error en el lado del servidor. Línea inicial (respuestas) 26/58 Algunos ejemplos típicos: 200 OK: la petición ha sido atendida y el documento respuesta viene a continuación 301 Moved Permanently 302 Moved Temporarily 303 See Other: Sólo en HTTP 1.1. Se ha movido el recurso, y en la cabecera Location: nos dicen dónde 404 Not Found: El recurso pedido no existe 500 Server Error: error en el servidor. Ejemplo: cgi-bin falla, o no tiene permisos,... 27/58

15 Ejemplo (respuesta a una petición GET) HTTP/ OK\r\n Date: Tue, 23 Jan :44:27 GMT\r\n Server: Apache/1.3.9 (Unix) Debian/GNU\r\n Last-Modified: Tue, 23 Jan :39:45 GMT\r\n ETag: "19e89f-22-3a6d7b91"\r\n Accept-Ranges: bytes\r\n Content-Length: 34\r\n Keep-Alive: timeout=15, max=100\r\n Connection: Keep-Alive\r\n Content-Type: text/html\r\n \r\n <html>\nesto es una prueba\n</html> 28/58 Líneas de cabecera Mismo formato que las cabeceras de correo y News (RFC 822, sección 3). HTTP/1.0: 16 cabeceras, ninguna obligatoria. HTTP/1.1: 46 cabeceras, Host: obligatoria en las peticiones (usada por los virtual hosts ). Se recomienda incluir en las peticiones al menos: From: (dirección de correo). User-Agent: (ej: Mozilla/4.7). Se recomienda incluir en las respuestas al menos: Server: (ej: Apache/1.3). Last-Modified: (fecha GMT, usado por las caches). 29/58

16 Algunas Cabeceras Accept [Request] Specifies which Internet media types are acceptable for the response and to assign preferences to them. Accept-Encoding [Request] Specifies which data format tranformations, confusingly called content (en)codings, such as compression mechanisms, are acceptable for the response and to assign preferences to them. Accept-Language [Request] Specifies which natural languages are acceptable for the response and to assign preferences to them. Useful for language negotation. Gives the sender s estimate of the amount of time since the response (or its revalidation) was generated at the origin server. Allow [Entity] Lists the set of methods supported by the resource identified by the Request-URI. The purpose is to inform the recipient of valid methods associated with the resource. Authorization [Request] Consists of credentials containing the authentication information of the client for the realm of the resource being requested Cache-Control [General] Specifies directives that must be obeyed by all caching mechanisms along the request/response chain. Connection [General] Specifies options that are desired for the particular connection and must not be communicated by proxies over further connections. Content-Encoding [Entity] Used as a modifier to the media-type, to indicate what additional data format transformations such as compression have been applied to the entity-body. Content-Language [Entity] Specifies the natural language(s) of the intended audience for the enclosed entity. Content-Length [Entity] Indicates the size (in octets) of the entity-body that is sent or that would have been sent if it has reen requested. Content-MD5 [Entity] An MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. Content-Type [Entity] Specifies the Internet media type of the entity-body that is sent or would have been sent if requested. Often includes a charset parameter specifying the character encoding. Date [General] Date and time at which the message was originated. 30/58 Expires [Entity] Gives the date/time after which the response is considered stale, for caching purposes. From [Request] The Internet address for the human user who controls the requesting browser or other client. Host [Request] Specifies the Internet host and port number of the resource being requested. Obligatory in all HTTP/1.1 requests. If-Modified-Since [Request] Used with a method to make it conditional: if the requested variant has not been modified since the time specified in this field, the server will not return the entity but information about this fact. If-None-Match [Request] Used with a method to make it conditional: a client that has previously obtained entities can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. Last-Modified [Entity] Indicates the date and time at which the origin server believes the variant was last modified. Restricts the request to some part(s), specified as range(s) of octets, in the resource. Referer [Request] Used by a client to specify, for the server s benefit, the address (URI) of the resource from which the Request-URI was obtained. Retry-After [Response] Indicates how long the service is expected to be unavailable to the requesting client. Server [Response] Contains information about the software used by the origin server to handle the request. User-Agent [Request] Contains information about the user agent (client) originating the request 31/58

17 Cuerpo del mensaje En las peticiones contiene datos de usuario o ficheros para subir. En las respuestas contiene el recurso pedido o texto explicando un error. Si hay cuerpo, normalmente hay algunas cabeceras relativas a él: Content-Type : tipo MIME de los datos (ej: text/html, image/png). Content-Length : número de bytes en el cuerpo. 32/58 MIME Multipurpose Internet Mail Extensions. RFC1521. Estándar abierto para enviar datos multimedia a través de correo-e Utilizado también para intercambiar documentos entre cliente y servidor en WWW Clasifica los contenidos según tipo/subtipo: Ejemplos: text/html text/plain image/gif image/jpeg video/mpeg audio/basic application/java application/x-tex application/pdf 33/58

18 HTTP 1.1 Es una evolución de HTTP 1.0. Uso de conexiones persistentes que permiten varias transacciones sucesivas (se evitan establecimientos de conexión). Facilidades específicas para máquinas virtuales (virtual hosts). Codificación por racimos, para respuestas dinámicas (envío antes de saber el tamaño total). Facilidades específicas para caches ( If-Modified-Since, If-Unmodified-Since ). 34/58 Conexiones persistentes Permiten que varias peticiones y respuestas sean transferidas usando la misma conexión TCP. Se usan por omisión en HTTP 1.1. Si se envía la cabecera Connection: close, el servidor cerrará la conexión después de cada respuesta. Posibilidad de entubar (pipeline). El servidor cerrará las conexiones inactivas pasado un plazo (ej: 10 segundos). 35/58

19 Virtual hosts Para tener virtual hosts es preciso indicar en cada petición a cuál de ellos se dirige. Por eso es obligatorio el uso de la cabecera Host. Si un servidor recibe una petición sin Host, debe devolver un mensaje de error (400 Bad Request). Los servidores también han de aceptar primeras ĺıneas de petición con URLs completas, en lugar de caminos (será lo habitual en versiones futuras). Ejemplo de petición mínima : GET /dir/index.html HTTP/1.1\r\n Host: gsyc.escet.urjc.es\r\n \r\n 36/58 Codificación por racimos Cabecera Transfer-Encoding: chunked. Usada por un servidor que quiere enviar trozos que ya tiene listos antes de tener todo. El cuerpo de cada mensaje por racimos contiene una serie de racimos, cada uno: Comienza por el tamaño de los datos del racimo, en hexadecimal, seguidos por ;, quizás algo más, y CRLF. Los datos, terminados por CRLF. Terminado por una ĺınea con 0CRLF. Seguido de footers (como cabeceras). Terminado en una ĺınea en blanco (CRLF). 37/58

20 Codificación por racimos HTTP/ OK\r\n Date: Fri, 27 Jan :00:00 GMT\r\n Content-Type: text/plain\r\n Transfer-Encoding: chunked\r\n \r\n 1b; datos que se pueden ignorar\r\n abcdefghijklmnopqrstuvwxyz\r\n 10\r\n abcdefg\r\n 0\r\n a-footer: su-valor\r\n another-footer: otro-valor\r\n \r\n 38/58 Facilidades para Cachés Los servidores deben responder siempre con la cabecera Date (con la fecha actual, en GMT). Los servidores han de entender If-Modified-Since y If-Unmodified-Since (los clientes pueden usarlos). Respuesta a If-Modified-Since : 304 Not Modified. Respuesta a If-Unmodified-Since : 412 Precondition Failed. 39/58

21 Representante (proxy) HTTP Intermediario entre un cliente y un servidor. Es por lo tanto a la vez cliente y servidor. Usos: cortafuegos, caches, etc. Las peticiones a una proxy incluyen la URL completa en la primera ĺınea del mensaje de petición. Pueden encadenarse varias proxies. Ejemplo de petición a una proxy: GET HTTP/1.0 40/58 Galletitas (cookies) Son pequeños ficheros que deposita el servidor en el cliente. Sirven para asociar estado a un conjunto de transacciones (peticiones/respuesta). Normalmente son datos asociados a un usuario (carro de la compra, cuenta de usuario, etc.) Las galletitas son generadas por los servidores, y presentadas por los clientes en ciertas ocasiones. Especificación original de Netscape, luego propuesta como RFC /58

22 Cabecera Set-Cookie Cabecera puesta por un servidor cuando quiere enviar una galletita. Formato: Set-Cookie: Nombre de la galletita y valor ( nombre=valor ). Fecha de caducidad ( expires=fecha ). Dominio, camino ( domain=dominio path=camino ). Para decidir más tarde si se envía una galletita o no. secure : si está marcada así, sólo se transmitirá sobre canales seguros (HTTPS). Ejemplo: Set-Cookie: unnombre=unvalor; expires=mon, 30-Jan :35:23 GMT; path=/dir; domain=mi.dominio.com; secure 42/58 Cabecera Cookie Cuando un cliente pide una URL, buscará en su lista de galletitas si hay alguna que tenga que enviar (mirando su domain por la cola, y su path por su cabeza). Enviará todas las galletitas en una única cabecera ( Cookie ). Dentro de esta cabecera, las galletitas se ordenarán de más a menos específicas (según su path ). No se consideran las galletitas con caducidad en el pasado (de hecho, se eliminan). Ejemplo: Cookie: unnombre=unvalor; otronombre=otrovalor 43/58

23 HTTPS HTTP sobre SSL (secure socket layer). La conexión TCP está cifrada, de forma que una tercera parte no puede conocer su contenido. Permite enviar datos sensibles a un servidor web, y recibirlos de él. Necesita de otros mecanismos (certificados, etc.) para ofrecer un nivel de seguridad razonable. Las URLs son 44/58 HTML HTML: Hypertext Markup Language. Utilizado para crear y reconocer documentos hipermedia Permite separar la presentación del contenido Un documento HTML es un conjunto de caracteres ASCII de 7 bits, con códigos para: Estilos del texto Títulos de documentos, secciones Párrafos Listas HiperEnlaces Formularios 45/58

24 Estado de HTML ( Las sucesivas versiones de HTML han intentado reflejar la práctica común entre los diversos fabricantes HTML 2.0 (Noviembre 1995, RFC1866) desarrollado en el marco del IETF recoge lo que era común a finales de 1994 HTML 3.0 (1995) propone versiones más ricas de HTML. Nunca fue consensuado como estándar pero añadió muchos elementos interesantes HTML 3.2 recoge lo que era común entre los navegadores en 1996 HTML 4.0 mejora HTML 3.2. Última versión: XHTML 1.0 ( HTML 4.0 es compatible hacia atrás con HTML: texto, multimedia, hiperenlaces HTML 4.0 soporta además: otras opciones multimedia, 46/58 lenguajes de scripts, hojas de estilo, mejora la impresión de documentos, facilita el uso de documentos a los incapacitados, internacionalización de documentos Más información: 47/58

25 Ejemplo de HTML <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML> <HEAD> <TITLE>Titulo</TITLE> </HEAD> <BODY> <H1>Cabecera de 1er nivel</h1> Parrafo<P> <HR> <ADDRESS>Una dirección</address> </BODY> </HTML> 48/58 WWW: URI, URL, URN ( URI: Uniform Resource Identifier es un medio para localizar un recurso en Internet de manera no ambigua Dos tipos de URI: URL, URN URL (Uniform Resource Locators) para representar direcciones de documentos hipermediales con la localización expĺıcita Casi todos los servicios de Internet tienen un tipo de URL La primera parte del URL especifica el método de acceso (protocolo) A continuación viene la dirección de la computadora en la que reside el servicio (opcionalmente puede llevar un puerto): 49/58

26 El resto de la URL especifica el camino y el nombre del fichero Opcionalmente puede llevar un nombre de sección, separado por #: Las computadoras que ofrecen un servicio de WWW suelen nombrarse con www al principio de su dirección: URL s relativas: heredan el protocolo, nombre de host y camino del documento padre (en el que aparece). Permiten que árboles completos puedan transportarse: URN: (Uniform Resource Name) Apunta a un recurso, ofreciendo transparencia de localización. RFC1738, RFC1808. Aún no están extendidas. 50/58 WWW: Ejemplos de URL file:// Trae y emite el sonido file:// Trae y muestra la imagen file:// Contenido del directorio Se conecta a un servidor HTTP y trae un fichero HTML ftp:// Abre una sesión FTP con y trae un fichero de texto gopher://iluso.ci.uv.es Gopher de iluso.ci.uv.es telnet://porky.urjc.es Abre una sesión telnet news:gsyc.test Lee las news 51/58

27 CGI CGI: Common Gateway Interface, truco utilizado para generar páginas de Web dinámicamente La página generada puede utilizar o no los datos de un formulario enviado por el cliente Los programas CGI se pueden escribir en cualquier lenguaje Los programas corren en procesos independientes iniciados por el servidor cada vez que llega una petición Ejemplo: <HTML> <HEAD> <TITLE>Formulario demo</title> </HEAD> <BODY> <FORM METHOD=GET ACTION= /cgi-bin/registro.pl > <PRE> Introduce tu nombre: <INPUT NAME= nombre_usuario SIZE=40> Introduce tu dirección <INPUT NAME= SIZE=40> </PRE> <INPUT TYPE= SUBMIT > </FORM> </BODY> </HTML> 52/58 Dos métodos para enviar los contenidos del formulario al servidor: GET, POST Con GET el browser envía los contenidos con la propia URL que envía al servidor: GET /cgi-bin/registro.pl?nombre_usuario=paco+gonzalez& = pgonzalez%40urjc%2es HTTP/1.0 Con GET el servidor le pasa los contenidos al programa CGI como una variable de entorno Con POST el ojeador puede enviar más datos. Lo hace incluyendo los contenidos del formulario después del comando POST: POST /cgi-bin/registro.pl HTTP/1.0 Content-type: application/x-www-form-urlencoded Content-length: 55 nombre_usuario=paco+gonzalez& =pgonzalez%40urjc%2es Con POST el programa recibe el contenido a través de la entrada estándar 53/58

28 Temas avanzados: nuevas características de los servidores WWW Los servidores pueden utilizarse también como un servidor suplente (proxy server): permite a clientes WWW aislados por cortafuegos usar Web como si el cortafuegos no existiese como un servidor cache: permite a todo cliente WWW que lo utilice como proxy, guardar temporalmente en un almacén local las últimas peticiones realizadas Otras características comunes a varios servidores WWW son el control de acceso y la generación de trazas 54/58 Temas avanzados: páginas activas en el servidor Servlets (java). ASP (Active Server Pages). PHP. Servidores sin estado? (Sesiones). Generación dinámica de contenidos (XML, wap, etc). Interacción con bases de datos. 55/58

29 Temas avanzados: motores de búsqueda Crecimiento exponencial del WWW. Tres mil millones de documentos en la actualidad. Es necesario utilizar algún tipo de guia para poder navegar Motores léxicos. Motores topológicos. Web semántica. 56/58 Referencias Definition of URL/URI syntax, RFC HTTP Made Really Easy. A Practical Guide to Writing Clients and Servers, por James Marshall. HTTP 1.0, RFC HTTP 1.1, RFC An Overview of SHTTP, por Adam Shostack. adam/shttp.html Persistent Client State. HTTP Cookies, Netscape. HTTP State Management Mechanism, RFC (Información sobre protocolos) 57/58

30 (Recursos para desarrolladores/administradores) (Libros O Reilly) apps/faq1.html (MIME) (Estándares) (RFC s) (Documentos de trabajo) 58/58