1. Prefacio 3 2. http: el protocolo de comunicación en Internet Bibliografía 11

Transcripción

1 DEPARTAMENTO DE INGENIERÍA INFORMÁTICA (DII): IT4128: GESTIÓN DE SISTEMAS EN INTERNET 2. HTTP 1.1 Autor: Justo N. Hidalgo Sanz

2 Contenido 1. Prefacio 3 2. http: el protocolo de comunicación en Internet Métodos de petición http Sintaxis de una petición Proxies Limitaciones de http HTTP Bibliografía 11

3 1. Prefacio Todo el mundo conoce internet, o al menos ha oído hablar de esta red de redes que ha revolucionado el concepto de globalidad (para bien y para mal). Nos encontramos en una época en la que la información es el recurso más búscado y más útil a la hora de realizar negocios y transacciones. Internet es el repositorio definitivo de todos esos datos. Sin embargo, la utilización sofisticada de internet aún no ha llegado a la mayoría de las empresas. Nuevas herramientas y plataformas han ido surgiendo en los últimos dos años intentando conseguir un desarrollo rápido de aplicaciones, que, a la vez, sean eficientes y útiles para los usuarios finales. En esta asignatura vamos a aprender algunas de las técnicas de creación de audience sites, es decir, portales o sitios web cuya infraestructura requiere algo más que unas cuantas líneas de código y un servidor web. Nos centraremos en el mundo de las aplicaciones de empresa, particularmente alrededor de los contenedores web y servidores de aplicaciones. No es una asignatura histórica o de referencia, sino que contaremos lo que se utiliza ahora mismo, y las tendencias del mercado. Existe tanta heterogeneidad de opciones que nos hemos tenido que decantar por un tipo de solución, que actualmente es líder del mercado: Java J2EE (Java 2 Enterprise Edition). El capítulo 1 nos introducirá en este mundo a través los conceptos básicos de la programación en internet. El segundo capítulo estudia en detalle uno de los pilares actuales de internet: XML (extensible Markup Language). El capítulo 3 se centra en el paradigma central de las aplicaciones cliente/servidor internet en Java: servlets. El capítulo 4 nos permite dar un paso más allá: JSPs (Java Server Pages). En el capítulo 5 descubriremos que tanto los servlets como JSPs como incluso XML forman parte de un plan más amplio, denominado J2EE. Por último, en el capítulo quinto esbozaremos la tendencia del sector hacia lo que se denominan servicios web, mediante las tecnologías SOAP (Simple Object Access Protocolo), UDDI (Universal Description, Discovery and Integration) y WSDL (Web Services Description Language). Este corto e intenso camino nos permitirá construir una aplicación web al estilo de lo que se realiza actualmente. Para conseguir una mayor comprensión, en la asignatura también se requiere la realización de tres prácticas de programación en las que el alumnos tendrá la oportunidad de sumergirse en tres elementos básicos de la programación de aplicaciones web en Java: http, XML, y Servlets y JSPs en J2EE. También, para aquellos alumnos que estén interesados en profundizar en temas que antes del comienzo de la asignatura les atraían, se propondrán una serie de trabajos optativos, sobre, por ejemplo: HTTP1.1,.NET, WAP (en GSM, GPRS, UMTS), TV-interactiva (estándares y empresas), comunicaciones inalámbricas en entornos locales (BlueTooth, etc.), programación en entornos empotrados, etc. Los trabajos deberán constar de: - Trabajo escrito. - Presentación. - Demo práctica (cuyo nivel será determinado por el trabajo en sí). La realización de estas prácticas implica un conocimiento de técnicas de orientación a objetos, y del lenguaje de programación Java, que NO se explicarán en clase. Disclaimer: este documento, y en general todos los capítulos que conforman la documentación detallada de la asignatura IT4128:Gestión de Sistemas en Internet no pretende ser un trabajo totalmente original del autor, sino que comprende ideas, conceptos, ejemplos tanto suyos como de otros autores ampliamente conocidos, y que se relatan en la Bibliografía. Si alguno de los autores o representantes se siente disconforme con la información aquí aportada, póngase en contacto con jhidalgo@nebrija.es

4 Pág: 4 de http: el protocolo de comunicación en Internet http (HyperText Transfer Protocol) es un protocolo de nivel de aplicación generalmente implementado sobre conexiones TCP/IP en el puerto 80 (por defecto). Se trata de un protocolo sin estado basado en el paradigma requestreply (petición respuesta). Los clientes realizan consultas sobre un servidor (que puede ser, por ejemplo, un servidor web), y éste le responde con información, o se inicia un procesamiento. Fue creado a comienzos de los 90 por Tim Berners-Lee, y se encuentra en su versión 1.1 (RFC 2616). 2.1 Métodos de petición http El protocolo define tanto qué tipos de peticiones se pueden realizar entre cliente y servidor, como la estructura de esos mensajes. http/1.0 establece tres tipos diferentes de mensajes: - GET. - POST. - HEAD. Http/1.1 tiene cinco más: - OPTIONS - PUT. - TRACE - DELETE - CONNECT Generalmente GET y POST son los más utilizados, y la mayor parte de las aplicaciones se bastan con ellos Método GET Se suele utilizar para acceder a recursos estáticos como documentos HTML e imágenes, aunque no es difícil verlo en aplicaciones dinámicas, incluyendo parámetros estáticos en la URL (Uniform Resource Location) de petición. Por ejemplo: Método POST Se utiliza cuando la información a devolver depende de la petición, y cuando hay muchos datos que enviar al servidor (el método GET sufre cuando hay muchos datos que enviar). POST ofrece una gama más amplia de mensajes a enviar/recibir, ya que permite multi-part messages, es decir diferentes tipos de ficheros o datos (text, binary,...). Se puede utilizar para invocar peticiones a applets Java o enviar bytes en crudo al servidor web. La diferencia principal con GET, de todas maneras, es que POST envía los parámetros de petición en el cuerpo del mensaje, mientras que GET los envía en la URL: - Las peticiones GET se pueden almacenar en el bookmark, lo cual no siempre es recomendable. - Existe una restricción en el tamaño GET (que depende del servidor, pues el protocolo no lo delimita: código 414) Método HEAD Un cliente invoca una petición HEAD cuando sólo quiere ver la cabecera de una respuesta. Tanto HEAD como GET no deberían de poder modificar el estado de una aplicación servidora, es decir, deben ser operaciones idempotentes Método LINK Solicita que la información de cabecera se asocie con un documento del servidor.

5 Pág: 5 de Método UNLINK Solicita que la información de cabecera se desasocie del documento del servidor Método OPTIONS Pide las opciones para comunicarse con el servidor. El URI puede sustituirse por * Método PUT Solicita que el cuerpo de la petición se almacene en el URI especificado Método DELETE Solicita que se borren los datos del URI especificado Método TRACE Solicita que se devuelva el cuerpo del mensaje sin modificar. Se utiliza para depurar.

6 Pág: 6 de Sintaxis de una petición La gramática completa se encuentra en la RFC. http_url= http: // host [ : port] [abs_path [? query]] Los mensajes enviados consisten de: - Una línea inicial. - Cero o más líneas de cabecera. - Una línea en blanco (i.e. CRLF). - Un cuerpo de mensaje opcional (un fichero, datos de consulta, resultado,...) No existe límite: existe el 414 (request URI too long) Petición Línea inicial de petición Tres partes separadas por espacios: - Nombre del método. - Path local del recurso pedido (parte de la URL tras el hostname: request URI (Uniform Resource Interface) - Versión del protocolo http utilizado Línea de cabecera Una por cabecera, del tipo: - Header-Name: value, terminado en CRLF En http 1.0 existen 16 cabeceras, todas opcionales. En http 1.1 existen 46 cabeceras: - Peticiones: o Host: obligatoria. o From: recomendable. o UserAgent: recomendable. - Respuestas: o Server: obligatoria. o Last-Modified: obligatoria. Cabeceras genéricas: - Date: Mon, 05 Mar :47:00 GMT - Upgrade: HTTP/1.1 Cabeceras petición: - Accept: text/html, video/mpeg, image/* - Accept-Encoding: compress, gzip, uuencode - Accept-Language: en, sp, fr - From: jhidalgo@denodo.com - Host: - User-Agent: Mozilla 1.1 Cabeceras respuesta: - Server: NCSA/1.3 - Age: Warning: code host[:port] "string

7 Pág: 7 de Cuerpo del mensaje Si un mensaje http incluye un cuerpo: - Content-Type: tipo MIME que es. - Content-Length: #bytes del cuerpo. Cabeceras relativas al cuerpo del mensaje: - Allow: métodos. Lista de métodos que se pueden usar en una URI. Acompaña al error Content-Base: uri. URI base para resolver direcciones relativas - Content-Encoding: gzip.codificación dada al cuerpo del mensaje - Content-Language: en, fr, sp.lenguaje en el que va el cuerpo del mensaje - Content-Length: longitud en bytes del cuerpo del mensaje - Content-Type: image/jpg. tipo de contenido que se transfiere. Si lo transmite el servidor, debe estar en consonancia con lo que especificó el cliente con la cabecera Accept - Location: uri. nueva dirección del documento - URI: uri. nueva localización de un documento. Acompaña a los códigos de servidor 201 (Created), 301 (Moved Permanently), o 302 (Moved Temporarily). Está en desuso. Tipos y subtipos Se usan para comunicar el formato del contenido de una transacción http. Los clientes lo utilizan en la cabecera accept para indicarle al servidor los formatos en los que pueden recibir datos. Los servidores lo utilizan por su parte con la cabecera Content-Type para indicar cuál es el contenido del mensaje. Son muy similares a los tipos MIME (Multipurpose Internet Mail Extension), llevan el formato tipo/subtipo. Los más comunes son: Tipo/subtipo Application/pdf Application/postscript Application/rtf Image/gif Image/jpeg Text/html Text/plain Video/mpeg Formato Pdf Ai, eps, ps Rtf Gif Jpeg, jpg, jpe Html, htm Txt Mpeg, mpg, mpe Respuesta Línea inicial de respuesta Tres partes separadas por espacios: - Versión http. - Código de respuesta de estados: o 1xx: mensaje de información. o 2xx: éxito de algún tipo. o 3xx: redirección a alguna otra URL. o 4xx: error en la parte cliente. o 5xx: error en la parte servidora. - Reason phrase: en inglés generalmente. Describe el código de estado Códigos de respuesta Errores 1xx: Continue: el principio de la petición se ha recibido y el cliente puede continuar (explicado más adelante) Switching protocolos: el servidor acepta cambiar un protocolo.

8 Pág: 8 de 11 Errores 2xx: OK: envío de los datos solicitados. La petición fue exitosa y el recurso solicitado se devuelve en el cuerpo del mensaje Created: se ha creado un URI y se envía su dirección Accepted: petición aceptada pero no procesada. Puede que no se procese Non-authoritative information: la información proviene de terceros, no del servidor No Content: respuesta sin cuerpo Reset Content: vaciar un formulario para que se puedan introducir más datos Partial Content: el servidor devuelve una parte de una página del tamaño solicitado. También indica qué parte de la página es. Errores 3xx: Multiple Choices: el URI de la petición hace referencia a más de un documento Moved Permanently: el URI de la petición ya no es de ese servidor. Se devuelve la nueva dirección Moved Temporarily: el URI se ha trasladado temporalmente See Other: el documento solicitado se encuentra en otra URI, y se debe solicitar a él. http 1.1. La URI se obtiene de la cabecera de respuesta Location: Not Modified: un URI no se ha modificado, por lo que se puede utilizar la copia local Use Proxy: se debe acceder al URI a través del proxy que se indica. Errores 4xx: Bad Request: error sintáctico en la petición Unathorized: se debe proporcionar la autentificación correcta Payment Required: sin implementar Forbidden: accceso prohibido por una razón que el servidor no puede o no quiere especificar Not Found: el documento no existe Method Not Allowed: el método utilizado por el cliente no funciona en esa URI Not Acceptable: el URI existe pero no con el formato aceptado por el cliente Proxy Authentication Required: el proxy necesita autorizar la petición antes de enviarla Request Timeout: la petición no se ha terminado en el tiempo establecido Conflict: la petición está en conflicto con otra, o con la configuración del servidor Gone: la URI no existe, está eliminada permanentemente del servidor Length Required: no se acepta la petición si no se proporciona la longitud Precondition failed: no se cumple una condición de la cabecera de la petición Request Entity too Large: el cuerpo de la petición es demasiado grande Request URI too Long: el URI de la petición es demasiado largo Unsupported Media Type: el cuerpo de la petición tiene un formato desconocido. Errores 5xx: Internal Server Error: una parte del servidor no funciona y no puede servir la petición (script que falla, sintaxis erronea, la aplicación no se puede ejecutar,...) Not Implemented: la petición no se puede llevar a cabo por el servidor Bad Gateway: el servidor o proxy recibió un error de otro servidor o proxy Service Unavailable: el servicio está temporalmente fuera de servicio Gateway Time-out: como el 408 pero siendo el gateway o el proxy el que produce el error http Version Not Supported: el servidor no tiene implementada esa versión de http.

9 Pág: 9 de Proxies A veces se utilizan proxies de salida. La única diferencia con respecto a la invocación a un servidor normal es que la primera línea incluye la URL completa del servidor destino, en vez de sólo el path, para que el proxy sepa a quién ha de enviarlo (esto para proxies no transparentes). 2.4 Limitaciones de http Proxies jerárquicos. - Caching. - Necesidad de conexiones persistentes. - Hosts virtuales. - Demasiados http1.0-compliant diferentes.

10 Pág: 10 de HTTP Clientes http Requisitos - Incluir la cabecera Host: en cada petición. Una IP puede ser multihomed: o o o Es muy necesario, debido a la proliferación de web sites. - Aceptar respuestas con datos chunked : chunked transfer encoding. Se trata de enviar respuestas antes de conocer su longitud total. El cuerpo chunk es el siguiente: o Se envía una serie de pedazos, donde cada chunk tiene la siguiente estructura: Línea con el tamaño en hexadecimal + [, <info>]crlf Datos + CRLF o Seguido de una línea con 0s. o Footers (opcionales) o Línea en blanco. - Una de dos: o Soportar conexiones persistentes. La apertura y cierre de conexiones http son operaciones muy costosas. Por ello, se mejora mediante un pipelining de peticiones. o Incluir la cabecera Connection:close en cada petición. - Manejar la respuesta 100: Continue. Útil para conexiones lentas o procesamientos muy cargados. El cliente sólo tiene que ignorarlo y, como mucho, actualizar su timeout Servidores http Requisitos - Cabecera Host: Es obligatoria. - URLs absolutas. En futuras versiones las peticiones utilizarán URLs absolutas. Para permitir la transición http1.1 acepta ambas opciones. Los clientes no están obligados. - Chunked transfer-encoding. Deben poder aceptarlos (no muy corriente) y están obligados a PODER enviarlos. - Conexiones persistentes o Connection:close. El servidor puede cortar una conexión ociosa. Si el servidor no quiere soportar persistencia, ha de enviar la cabecera Connection:close en su respuesta. - Respuesta 100: Continue : igual que en el cliente. - Cabecera Date: : los servidores deben marcar toda respuesta menos la 100:Continue con esta cabecera GMT (Greenwich Mean Time). - Cabeceras If-Modified-Since y If-Unmodified-Since o Envíame este recurso sólo si [no] ha cambiado desde. o Obligatorio para servidores. o Si, sin la cabecera el resultado fuera erróneo se debe ignorar la cabecera y enviar el código de error. o If-modified-since: Si se ha modificado, se envía el recurso. Si no: 304. o If-unmodified-since: Si se ha modificado: Métodos GET, HEAD: han de estar implementados. POST suele estarlo. Resto: Peticiones HTTP 1.0: han de permitirse peticiones http 1.0.

11 Pág: 11 de Bibliografía J2EE1.3.1 G. Coulouris, J. Dollimore, T. Kindberg. Sistemas Operativos Distribuidos, Tercera Edición. Addison-Wesley. A. Tanenbaum. Distributed Operating Systems. Prentice Hall R. Orfali, D. Harkey. Client/Server Survival Guide, 2 nd. Edition. Van Nostrand Reinhold. R. Orfali, D. Harkey. Client/Server Programming with Java and CORBA, 2 nd. Edition. Van Nostrand Reinhold. W. Keith Edwards. Core JINI. Prentice Hall. M. Henning, S. Vinoski. Advanced CORBA Programming with C++, 1 st. Edition. Addison-Wesley, Q. H. Mahmoud. Distributed Programming with Java, 1 st. Edition. Manning. M.E. Fayad, D.C. Schmidt, R. E. Johnson. Building Application Frameworks (Object-Oriented Foundations of Framework Design). Ed. Wiley, A. Silberschatz, J. Peterson, P. Galvin. Operating System Concepts, 4 th. Edition. Addison-Wesley.