Tema 2 Protocolo HTTP y el servicio www (6) PDF
Document Details
Uploaded by Deleted User
Escuela Politécnica Superior de Linares, Universidad de Jaén
2024
Juan Carlos Cuevas Martínez
Tags
Related
- World Wide Web & Email Protocols (PDF)
- TUP_4C_DABD_TEO_U3_ComunicacionNavegacion.pdf
- TELEMATICA 3 - CAPA DE APLICACION Y SERVICIOS DE RED - HTTP.pdf
- ITN Module 15: Application Layer PDF
- Sanjivani K.B.P. Polytechnic 2023-2024 Practice Test PDF
- BCS101 - Computer Science Fundamentals Lecture Notes Fall 2024/2025 PDF
Summary
Este documento explora el protocolo HTTP y el servicio web. Se analizan las principales características, componentes funcionales como HTML, URIs, y los distintos protocolos HTTP (HTTP/1.1, HTTP/2, HTTP/3). El documento también explora la evolución del protocolo y su rendimiento.
Full Transcript
Autor: Juan Carlos Cuevas Martínez Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Pr...
Autor: Juan Carlos Cuevas Martínez Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 2 Contenido 1. Introducción. 2. Direccionamiento. 3. Evolución del protocolo HTTP. 4. Características del protocolo HTTP. 5. Métodos HTTP. 6. Códigos de estado y frases de respuesta. 7. Cabeceras de HTTP. 8. Funcionamiento del protocolo HTTP. 9. Protocolo HTTP/1.1. 10. Protocolo HTTP/2. 11. Protocolo HTTP/3. 12. Rendimiento en comunicaciones web. 13. Websockects. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 3 Bibliografía Bibliografía básica Ludin S y Garza, J., “Learning HTTP/2. A practical guide for beginners”. O’Reilly, 2017. Pollard B., “HTTP/2 in action”. Manning, 2019. Grigorik I., “High Performance Browser Networking”. O’Reilly, 2013. Disponible en: https://hpbn.co/. TANENBAUM, Andrew S. Computer Networks, Global Edition. Pearson Universidad, 2021. ISBN 9781292374062. Forouzan, B., “TCP IP Protocol Suite”, 4ª Ed, Mc Graw Hill. Kozierok, C., “The TCP IP guide: a comprehensive , illustrated internet protocols reference”, No Starch Press. Reference For Comments (RFC). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 4 Bibliografía Bibliografía complementaria Kurose, J., Ross, K., “Redes de Computadores. Un enfoque descendente basado en Internet”. 4ª Edición, Pearson Education. Comer, D., “Computer networks and internets”, Prentice Hall. Stallings W. “Comunicaciones y redes de computadores”, 7ª Edición. Prentice Hall. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 5 1. Introducción Principales componentes funcionales de la Web La World Wide Web, WWW o simplemente Web es un fenómeno que pocos pudieron prever. Todo nació del hiper-texto: simplemente una forma de enlazar unos documentos con otros y transferirlos. Conjuntamente al éxito de las redes TCP/IP ha llevado a lo que es hoy en día. Así pues los componentes funcionales más importantes de la web son: Hypertext Markup Language (HTML). Hypertext Transfer Protocol (HTTP). Uniform Resource Identifiers (URIs). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 6 1. Introducción Principales componentes funcionales de la Web Hypertext Markup Language (HTML): El lenguaje HTML está formado por texto y marcas sencillas llamadas etiquetas (tags). Permite enlazar documentos, así como de dotarles de estructura y de la capacidad de incorporar todo tipo de contenido. HTML se ha convertido en el estándar de hiper-texto, así como ha propiciado la aparición de otros lenguajes, como XML, XHTML, etc. Hypertext Transfer Protocol (HTTP): HTTP es el protocolo de aplicación de la torre TCP/IP que implementa el servicio Web a través de la transferencia de los documentos HTML y de otros muchos tipos. HTTP comenzó como un protocolo muy simple para enviar solamente documentos HTML. En la actualidad posibilita gran variedad de funciones sofisticadas como la transferencia de todo tipo de documentos, streaming de varios ficheros por una conexión, uso de proxy, acceso a recursos con autenticación y caché, entre otras. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 7 1. Introducción Principales componentes funcionales de la Web Uniform Resource Identifiers (URIs): Los URIs son usados para definir etiquetas que identifiquen de manera global y unívoca cualquier recurso en Internet. Actualmente los URI no se limitan al servicio Web. Existen dos categorías: los Uniform Resource Locators (URLs) y los Uniform Resource Names (URNs). Tras la aparición de los URIs, los URLs y los URNs pasaron a integrarse como URIs Además, como parte fundamental también están: Servidores WEB. Navegadores WEB. Los usuarios. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 8 1. Introducción Hypertext Markup Language (HTML) Inventado en 1990 por el inventor de la web Tim Berners-Lee. Es una aplicación del Standard Generalized Markup Language (SGML) que es el estándar ISO 8879:1986. HTML se organiza a través de la inclusión de etiquetas (tags) que deben tener un formato concreto en texto plano y que van encerradas entre los símbolos ‘’. Ejemplo , o Correspondiéndose normalmente una etiqueta de cierre para una de las anteriores (esto es Hello obligado en XHTML). Ejemplo: Esto es un párrafo Hello Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 9 1. Introducción ¿Qué es una aplicación web? La respuesta evoluciona en función de las prestaciones. En un principio: conjunto de documentos, imágenes, etc., relacionados entre sí a través de hipervínculos. Posteriormente: Junto a los documentos HTML, imágenes, etc., aparecen programas que realizan una determinada función y que son ajenos al servidor http concepto de aplicación de servidor Por su parte, los navegadores evolucionan, permitiendo la ejecución de aplicaciones: Aplicaciones en el cliente + aplicaciones en el servidor Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 10 1. Introducción ¿Qué es una aplicación web? Las aplicaciones web se fundamentan en ideas y protocolos como: CLIENTE-SERVIDOR. TCP/IP (HTTP). MIME. LENGUAJE DE MARCAS (HTML, XML). Necesidad de un direccionamiento para identificar un recurso. Para ello se introduce el Indentificador de Recurso Uniforme (URI). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 11 2. Direccionamiento El direccionamiento a nivel de aplicación puede ser visto como redundante: con tan sólo con una dirección IP y un puerto ya se puede acceder a un servicio. ¿Y entonces?… Realmente existe una necesidad añadida: ¿Cómo podemos referenciar o acceder a recursos concretos (texto, imágenes, vídeos, etc.) que están disponibles a través de una aplicación? Se necesita una dirección de aplicación: IP: Máquina Proceso: Servidor web Recurso: URI Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 12 2. Direccionamiento Así, paralelo al crecimiento de la web y el desarrollo de HTTP, surgen los Identificadores Uniformes de Recurso o URIs (Uniform Resource Identifier). Los URI permiten identificar de manera unívoca a un recurso del servicio web sin necesitar enviar varias instrucciones. Aunque surgieron de la tecnología web, se usan hoy en día en muchas otras aplicaciones y en sí han cobrado importancia en sí mismos como un ente separado de la web y HTTP. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 13 2. Direccionamiento Ficha Uniform Resource Identifier (URI): Generic Syntax RFC 3986 Uniform Resource Identifier (URI): Generic Syntax Estándar 66. Autores: T. Berners-Lee, R. Fielding, L. Masinter. Fecha: Enero 2005. ASCII. BCP: BEST Deja obsoletas: RFC 2732, RFC 2396 y RFC1808. CURRENT PRACTICE Actualiza: RFC1738. La actualizan: RFC 6874, Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers, febrero 2013. BCP 190 RFC 8820 URI Design and Ownership, June 2020. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 14 2. Direccionamiento Categorías de URIs Uniform Resource Locators (URLs): Una URL es una URI que permiten localizar un recurso completamente en una red, a través de la indicación del protocolo de comunicaciones y cualquier otro aspecto necesario, tal como el host, usuario y clave, ruta, nombre e incluso parámetros de funcionamiento. Uniform Resource Names (URNs) [RFC8141]: Un URN es una forma global y única de nombrar a un recurso sin especificar la forma en la que se accede a él ni donde está. URI La RFC 3986 establece que en las especificaciones URL URN se debe emplear URI en ACCESO DENOMINACIÓN LOCALIZACIÓN vez de los otros dos términos, los cuales son más restrictivos. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 15 2. Direccionamiento URL (Uniform Resource Locators) Formato Definido inicialmente en la RFC 1738, Uniform Resource Locators (URL) (diciembre 1994). Esta RFC ha sufrido diversas modificaciones y actualizaciones, las cuales han afectado a veces a solo una parte de la misma: La dejan obsoleta: RFC 4248. The telnet URI Scheme, octubre 2005 RFC 4266. The gopher URI Scheme, noviembre 2005 La actualizan RFC 1808, dejada obsoleta también por la RFC 3986. RFC 2368, dejada obsoleta por la RFC 6068 The 'mailto' URI Scheme, octubre 2010. RFC 2396, dejada obsoleta también por la RFC 3986. RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, enero 2005 RFC 6196, Moving mailserver: URI Scheme to Historic, marzo 2011 RFC 6270, The 'tn3270' URI Scheme, junio 2011 Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 16 2. Direccionamiento URL (Uniform Resource Locators) Formato La sintaxis genérica de los URI consiste en una secuencia jerárquica de componentes: Esquema (scheme). Autoridad (authority) Ruta (path) Petición (query) Fragmento (fragment) RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, enero 2005 Actualizada por las RFC6874, RFC7320 y RFC8820. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 17 2. Direccionamiento URL (Uniform Resource Locators) Sintaxis ABNF URI = scheme ":" hier-part[ "?" query ][ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 18 2. Direccionamiento URL (Uniform Resource Locators) Formato ://:@:/?#fragment scheme: define el plan (URL scheme) de acceso al recurso, normalmente el protocolo a usar. user y password: es una aplicación de userinfo [RFC3986 3.2.1], no se debe emplear, están declarados obsoletos. host: lugar en la red, normalmente un nombre de dominio o una dirección IP. port: puerto a través del cual se accede al servicio. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 19 2. Direccionamiento URL (Uniform Resource Locators) Formato url-path: camino del recurso dentro del Host. query: información adicional opcional aportada al servidor cuando el recurso es accedido. Se pueden enviar varias separándolas por el carácter ‘&’. fragment: identifica una parte concreta del recurso a la que se quiere acceder u otro tipo de representación alternativa. Realmente no es parte de la URL y no se envía al servidor. Lo retiene el programa cliente para saber como organizar la información a mostrar. El fragmento se marca con el carácter ‘#’. Ejemplos ftp://usuario:[email protected]/archivo.exe https://platea.ujaen.es/course/view.php?id=5763 Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 20 2. Direccionamiento URL (Uniform Resource Locators) Caracteres reservados, no reservados e inseguros en las URIs Las URIs se forman, como se ha visto, conforme a una estructura formada por caracteres delimitados por otros caracteres especiales. Caracteres reservados: sirven como delimitadores, si un carácter entra en conflicto con un delimitador, no siendo su función cumplir con la estructura de la URI se debe emplear su codificación con ‘%’ y el código ASCII en hexadecimal. reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" Los caracteres no reservados son aquéllos que están permitidos en la URI pero no tienen reservado un propósito concreto: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 21 2. Direccionamiento URL (Uniform Resource Locators) Caracteres reservados, no reservados e inseguros en las URIs Algunos caracteres, si se emplearan para formar una URI, podrían romper la coherencia de la misma. Estos caracteres se denominan caracteres inseguros y se sustituyen por el símbolo ‘%’ seguido por el código ASCII en hexadecimal. Por ejemplo el espacio en blanco no está permitido y se sustituye por %20 (20h = 32 que es el código ASCII del espacio en blanco). pct-encoded = "%" HEXDIG HEXDIG Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 22 2. Direccionamiento URL (Uniform Resource Locators) Tabla con los códigos ASCII de caracteres inseguros para las URLs Carácter Codificación Carácter Codificación Carácter Codificación %20 < %3C > %3E # %23 % %25 { %7B } %7D | %7C \ %5C ^ %5E [ %5B ] %5D & %26 ` %60 ; %3B / %2F ? %3F : %3A @ %40 = %3D Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 23 2. Direccionamiento URL (Uniform Resource Locators) URL del protocolo HTTP Normalmente la URL para el servicio web es muy sencilla, pero en su mayor detalle sería como sigue: http://:/?# El puerto para el esquema http es por defecto el 80. Para el esquema https (http sobre SSL/TLS) el puerto es el 443. No se usan los parámetros, y las peticiones sirven para comunicar aspectos adicionales al servidor. Se han reemplazado los fragmentos por las referencias que se usan dentro de los documentos HTML. Generalmente una URL del servicio web es así de sencilla: http:/// Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 24 3. Evolución del Protocolo HTTP Protocolo sencillo surgido de la necesidad de enviar y recibir documentos de hipertexto en el CERN que es el Instituto Europeo de Investigación Nuclear. La primera versión creada por estos investigadores se denominó posteriormente como HTTP/0.9. Aún hoy sigue siendo fundamentalmente un protocolo de pregunta/respuesta. Las versiones posteriores han sido la HTTP/1.0, la HTTP/1.1, la HTTP/2 y la HTTP/3. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 25 3. Evolución del Protocolo HTTP Versión HTTP/0.9 La primera versión desarrollada (1991). No fue estandarizada. No tuvo una RFC o un número de versión. Era tan sólo una especificación de un par de páginas y que permitía enviar solamente documentos de hipertexto. La petición era una sola línea con el método (GET) y la ruta al recurso. La respuestas era un texto ASCII. No había códigos de error (eran parte del texto legible). No permitía cabeceras en las peticiones. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 26 3. Evolución del Protocolo HTTP Versión HTTP/1.0 Durante los primeros años de uso de la primera versión, muchas ideas fueron surgiendo dando lugar a HTTP/1.0. La versión HTTT/1.0 aunó las características más comunes y significativas de la evolución que había existido en los primeros años de la WorldWideWeb (en un principio WorldWideWeb no se separaba). El primer documento publicado fue en mayo de 1996 en la RFC 1945 (aunque realmente es un memorándum) Esta especificación se usó durante años antes de su publicación en la RFC 1945. Se convirtió en un protocolo de envío de mensajes completo: Especificación de las peticiones de cliente y respuestas de servidor. Nuevos métodos: HEAD y POST. Se añadieron los códigos de estado a las respuestas: 1xx, 2xx, 3xx, 4xx y 5xx. Peticiones condicionales: permitían no descargar un recurso si no había cambiado en el servidor. Soporte a todo tipo de contenido (adaptó ciertos aspectos de las extensiones MIME diseñadas para el correo electrónico). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 27 3. Evolución del Protocolo HTTP Versión HTTP/1.0 Limitaciones Sin embargo dado al auge de Internet en la segunda mitad de los años 90 del siglo XX pronto quedaron de manifiesto sus limitaciones: Cada sitio web tenía que estar en un servidor diferente (contar con una IP diferente o un puerto diferente, lo cual era inviable para un servicio global). Cada petición (conexión TCP) tan sólo podía obtener un recurso web a la vez. Falta de soporte para características de mejora del funcionamiento como caché, proxy y descarga parcial de recursos. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 28 3. Evolución del Protocolo HTTP Versión HTTP/1.1 Para solucionar los problemas de HTTP/1.0 y adaptarse al creciente uso de la web, el primer borrador apareció en la RFC 2068 en enero de 1997. Fue revisado y posteriormente publicado en junio de 1999 en la RFC 2616 como “Hypertext Transfer Protocol –HTTP/1.1”. Mantiene compatibilidad hacia atrás con las versiones HTTP/1.0 y HTTP/0.9. Esta versión se acompaña de la RFC 2617 que versa sobre seguridad y autenticación. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 29 3. Evolución del Protocolo HTTP Versión HTTP/1.1 Evolución de las RFC La RFC 2616 quedó obsoleta tras la publicación de las siguientes RFCs en junio de 2014: RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication Este trabajo ha sido llevado a cabo por el grupo Hypertext Transfer Protocol Bis (httpbis) del IETF que fuera iniciado en 2006. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 30 3. Evolución del Protocolo HTTP Versión HTTP/1.1 Evolución de las RFC Se complementa con las siguientes nuevas RFCs: RFC7236: Initial HTTP Authentication Scheme Registrations RFC7237: Initial HTTP Method Registrations Otras especificaciones relacionadas: RFC7238: The HTTP Status Code 308 (Permanent Redirect) RFC7239: Forwarded HTTP Extension RFC7240: Prefer Header for HTTP Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 31 3. Evolución del Protocolo HTTP Versión HTTP/1.1 Evolución de las RFC En 2022, tras la estandarización de HTTP/3 se vuelven a unificar muchas de las RFCs anteriores en una sola la RFC 9110 HTTP Semantics, además de aparecer otras actualizaciones y una nueva RFC para HTTP/1.1. RFC 9110 HTTP Semantics Deja obsoletas: RFC 2818: HTTP Over TLS. RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests. RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication. RFC 7238: The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). RFC 7615: HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields. RFC 7694: Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding. Actualiza: RFC 3864: Registration Procedures for Message Header Fields RFC 9111 HTTP Caching: deja obsoleta la RFC 7234 Hypertext Transfer Protocol (HTTP/1.1): Caching. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 32 3. Evolución del Protocolo HTTP Versión HTTP/1.1 Evolución de las RFC La nueva especificación de HTTP/1.1 es la RFC 9112 HTTP/1.1, que deja obsoleta partes de la RFC 7230. Por lo tanto, la nueva especificación de HTTP/1.1 queda conformada por: RFC9110 HTTP Semantics. RFC9111 HTTP Caching. RFC9112 HTTP/1.1. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 33 3. Evolución del Protocolo HTTP Versión HTTP/1.1 Mejoras introducidas en la versión HTTP/1.1 Soporte de Múltiples nombres de host: En la versión HTTP/1.0 no había manera de especificar el nombre del host al que quería conectarse el cliente. Cada servidor web tenía que estar en una IP diferente. Se consumían demasiadas direcciones IP para el servicio. Con HTTP/1.1 se permite a un servidor web manejar peticiones para un gran número (centenares) de servidores virtuales diferentes (se consigue gracias a la cabecera host). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 34 3. Evolución del Protocolo HTTP Versión HTTP/1.1 Mejoras introducidas en la versión HTTP/1.1 Conexiones persistentes: HTTP/1.1 permite a un cliente enviar múltiples peticiones para obtener recursos del servidor en una sola conexión TCP. Con HTTP/1.0 cada petición tenía que usar una conexión TCP diferente. Las peticiones se resuelven (responden) en el mismo orden que se han hecho. Selección de recurso parcial: En HTTP/1.1 un cliente puede solicitar solamente una parte de un recurso sin tener que descargarlo en su totalidad. Mejora considerablemente el aprovechamiento del ancho de banda, sobre todo en la descarga de ficheros de gran tamaño. Esto se consigue gracias a la cabecera range. Implementación de la cabecera Transfer-Encoding: establece la forma en la que se envía el mensaje. Particularmente permite el envío de contenidos que no se sabe su longitud de antemano con el tipo “chunked” o “por trozos”. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 35 3. Evolución del Protocolo HTTP Versión HTTP/1.1 Mejoras introducidas en la versión HTTP/1.1 Mejora del uso de caché y proxy: Se introducen mejoras para aumentar el rendimiento y seguridad de estas técnicas. Negociación del contenido: En HTTP/1.1 se permite tanto al cliente como al servidor intercambiar información para ayudar a seleccionar el recurso más apropiado, versión o variante del mismo. Ejemplo que un cliente en un móvil pueda ver las páginas adaptadas a terminales móviles en vez de las que están diseñadas para equipos de escritorio, o si lo prefiere ver éstas últimas. Mejora general en la seguridad de HTTP/1.1 frente a HTTP/1.0. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 36 3. Evolución del Protocolo HTTP Versión HTTP/2 En 2015 se lanzó la versión HTTP/2.0, fruto del trabajo del grupo HTTPbis del IETF. Su intención no es dejar obsoleta la versión HTTP/1.1, sino ofrecer una alternativa. Ya es toda una realidad y algunos de los servicios más usados ya van sobre HTTP/2: Google, Facebook, etc. Fue publicado en la RFC 7540 “Hypertext Transfer Protocol Version 2 (HTTP/2)“ en mayo de 2015 y dejada obsoleta en 2022 por la RFC 9113. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 37 3. Evolución del Protocolo HTTP Versión HTTP/2 Origen HTTP/2 parte de los esfuerzos por mejorar el rendimiento del protocolo HTTP/1.1 en el nuevo entorno del servicio web e Internet del siglo XXI. Incluso se intentó reemplazar TCP por SCTP como protocolo de transporte para aprovechar la capacidad de éste de gestionar varios flujos de datos. Problemas de HTTP/1.1: Las peticiones se tienen que resolver en orden. Cabeceras repetitivas y demasiado largas. Las carencias de HTTP/1.1 obligaban a buscar soluciones “ingeniosas” para solventarlas (por ejemplo el “domain sharding”). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 38 3. Evolución del Protocolo HTTP Versión HTTP/2 Origen En 2012 se inició el trabajo en el grupo de trabajo de HTTP para crear HTTP/2 partiendo de SPDY (o Speedy), desarrollado por Google para el navegador Chrome, que tenía muy buenas Torre de protocolos de SPDY innovaciones: Fuente: www.chromium.org/spdy/spdy- Compresión de cabeceras whitepaper Varios flujos simultáneos. Priorización de peticiones. Mensajes de servidor. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 39 3. Evolución del Protocolo HTTP Versión HTTP/2 Algunas de las nuevas funcionalidades que aporta son: Mezcla de mensajes de petición y respuesta en la misma conexión. Codificación eficiente de las cabeceras. Priorización de peticiones, para conseguir que aquellas con más prioridad se envíen antes, aumentando la tasa de transferencia para éstas. En resultado usará menos conexiones TCP. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 40 3. Evolución del Protocolo HTTP Versión HTTP/3 Es fruto del grupo de trabajo QUIC del IETF. Surge de la necesidad de conseguir una menor latencia en las comunicaciones y solventar algunos problemas que presenta TCP cuando se pierde un segmento (Head of line blocking): nace QUIC. HTTP/3 comienza como HTTP-over-QUIC. Es en 2018 cuando empieza a denominarse como en la actualidad. El primer borrador de HTTP-over-QUIC data de noviembre de 2016. Hoy en día es ya soportado en la mayoría de navegadores. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 41 4. Características generales del protocolo HTTP Modelo de operación y comunicación Cliente/Servidor HTTP es un protocolo cliente/servidor basado en peticiones y respuestas. Su objetivo principal es intercambiar recursos (no hay limitación en cuanto qué considerar un recurso), la mayoría de ellos identificados mediante una URI. PETICIÓN (REQUEST) INTERNET Cliente HTTP, agente de usuario RESPUESTA (RESPONSE) Servidor origen (user agent). Ejemplo: Servidor HTTP navegador (web browser) o servidor web Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 42 4. Características generales del protocolo HTTP Modelo de operación y comunicación Cliente/Servidor Petición del cliente: Las peticiones del cliente son formateadas según la especificación de HTTP en un mensaje de petición: Incluyen la información necesaria para identificar la operación a realizar y el recurso deseado. Parámetros adicionales necesarios para el servidor: campos (fields) enviados en la cabecera, también conocidos como cabeceras (header fields). Pueden, en ciertos casos, incluir también un recurso. Respuesta del servidor: El servidor interpreta la petición del cliente, la procesa, toma las acciones relevantes para dicha petición y elabora un mensaje de respuesta. El mensaje de respuesta contendrá: Un código que indicará si la petición ha tenido éxito o no. Nuevos campos para completar la respuesta y/o el recurso incluido. Generalmente, un recurso si la petición así lo solicitó y ésta ha podido ser atendida correctamente por el servidor. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 43 4. Características generales del protocolo HTTP Modelo de operación y comunicación Cliente/Servidor Cabeceras de petición Cabeceras Generales: Se refieren al mensaje en sí mismo, no dependen de si es una petición o una respuesta. No dependen del tipo de recurso solicitado. Aportan información de cómo debe ser procesada la petición o proporcionan información adicional. Cabeceras de Petición: Aportan detalles de la petición del cliente. Informan de aspectos más concretos de cómo se tiene que procesar la petición. Cabeceras de Entidad: Describen la entidad contenida en el cuerpo de la petición si ésta existe. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 44 4. Características generales del protocolo HTTP Modelo de operación y comunicación Cliente/Servidor Cabeceras de respuesta Cabeceras Generales: Igual que en la petición, si bien algunas son más comunes de peticiones y otras de respuestas. Cabeceras de Respuesta: Aportan información adicional que complementa a la línea de estado. El servidor puede añadir información adicional, incluso en el cuerpo de la respuesta, aunque esto es más habitual en caso de error. Cabeceras de Entidad: Describen la entidad contenida en el cuerpo de la petición si ésta existe. Son las mismas que pueden aparecer en una petición, pero son más habituales en los mensajes de respuestas. Es posible que en la respuesta haya cabeceras de entidad pero no esté presente el recurso, como ocurre cuando es una respuesta a una petición HEAD. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 45 4. Características generales del protocolo HTTP Modelo de operación y comunicación Cliente/Servidor con intermediarios HTTP soporta que entidades intermediarias cambien/modifiquen las peticiones en función de su tarea. Estas entidades pueden ser: proxis, pasarelas (gateways) o túneles. PETICIÓN 1 PETICIÓN 2 PETICIÓN 3 RESPUESTA 3 RESPUESTA 2 RESPUESTA 1 Cliente Intermediario 1 Intermediario 2 Servidor HTTP HTTP Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 46 4. Características generales del protocolo HTTP Extensibilidad de HTTP Aparte de lo definido en las RFC estándar, HTTP tiene diversas formas de poder ser extendido sin que esto implique la modificación de estos documentos o la creación de una nueva versión. Esto se debe a que la semántica del protocolo no es dependiente de la versión. Puede ser extendido en métodos, códigos de estado, nombres de campos de cabecera o tráiler, e incluso, dentro de los valores de cabeceras existentes como los esquemas de autenticación y las directivas de caché. Se desaconseja que las extensiones sean dependientes de una versión en concreto, pero se admite cuando es inevitable. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 47 5. Métodos HTTP Existen 8 métodos, y siempre se deben Nota: El motivo de que se escribir (y enviar) en mayúsculas. denominen métodos, y no comandos (lo cual a todos los Los más usados son GET, POST y HEAD. efectos sería igual), es por la herencia de la definición del Los otros cinco son: OPTIONS, PUT, protocolo en la versión 1.0 (RFC 1945). Ésta define a DELETE, TRACE y CONNECT. HTTP en su introducción como: Un servidor de propósito general debe dar «un protocolo genérico, sin estados, orientado a objetos el soporte a GET y HEAD, los demás son cuál puede ser usado para muchas tareas, …» Así pues, opcionales. de la OOP (object-oriented programming), se deriva que los objetos ejecutan su cometido a través de métodos. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 48 5. Métodos HTTP Métodos más usados GET: Solicita la transferencia desde el servidor HTTP de la representación actual del recurso objetivo especificado en el URI. HEAD: Como GET, salvo que el servidor no envía el recurso en concreto, tan sólo las cabeceras. Se usa para comprobar la existencia de recursos, estado o tamaño. POST: Permite al cliente enviar información al servidor, normalmente para que sea procesada por este o por alguna aplicación en dicho servidor. La URL contiene el recurso que debe recibir y procesar los datos enviados por el cliente. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 49 5. Métodos HTTP Métodos no habituales OPTIONS: Informa acerca de las capacidades de comunicación de un recurso, del servidor o de un intermediario. Si se especifica una URI, se obtendrá información relevante sobre cómo accederlo. Si se especifica un asterisco ‘*’, la petición será sobre el servidor mismo. PUT: Permite enviar un recurso objetivo especificado en la URI al servidor (no es común, es más empleado en APIs REST), creándose o reemplazándose el recurso destino. DELETE: Permite borrar un recurso en el servidor (nada habitual, más empleado en API REST). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 50 5. Métodos HTTP Métodos no habituales TRACE: Permite al cliente solicitar una copia de la petición enviada al servidor, normalmente para diagnosis. CONNECT: Informa al receptor del método de que debe establecer un túnel con el servidor identificado en la URI. Se emplea normalmente para que un proxy se pueda convertir en un túnel dinámicamente, lo que también se puede asegurar con TLS. Ejemplo: CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 51 5. Métodos HTTP Métodos HTTP Ejemplo: comando OPTIONS OPTIONS * HTTP/1.1 HOST:WWW10.UJAEN.ES HTTP/1.1 200 OK Date: Thu, 03 Oct 2013 07:32:06 GMT Server: Apache Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 0 Content-Type: text/plain Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 52 5. Métodos HTTP Propiedades comunes de los métodos La documentación de HTTP agrupa en una serie de categorías sus métodos, en función del impacto que pueden ocasionar en el servidor: Métodos seguros. Métodos idempotentes. El IANA mantiene una lista con todos los métodos en https://www.iana.org/assignments/http- methods/http-methods.xhtml. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 53 5. Métodos HTTP Propiedades comunes de los métodos Métodos seguros Son aquellos cuyo comportamiento básico es esencialmente de solo lectura, por lo que se les presupone que su impacto en un servidor no es perjudicial (en un principio) ya que no pueden ocasionar una alteración de los recursos proporcionados por éste, ni producir efectos colaterales indeseados. Los métodos seguros son GET, HEAD, OPTIONS y TRACE. Por el contrario, los que solicitan que el servidor procese algo, o pueden conducir a cambios en el mismo, se denominan inseguros, como lo son CONNECT, POST, PUT y DELETE. Que sean considerados inseguros no significa que los servidores no los permitan nunca (de hecho POST es un método ampliamente usado, y fundamental actualmente). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 54 5. Métodos HTTP Propiedades comunes de los métodos Métodos idempotentes Un método es idempotente cuando la ejecución de éste, independientemente de las veces que se ejecute, arroja el mismo resultado que si se hubiera ejecutado una sola vez. Inherentemente, todos los métodos seguros, junto con PUT y DELETE son idempotentes (quedan fuera CONNECT y POST). POST, al requerir, normalmente, del procesado de cierta información por parte del servidor, puede generar diferentes respuestas para la misma petición. Sin embargo, secuencias de métodos idempotentes pueden conllevar un comportamiento no idempotente (una secuencia es idempotente cuando la ejecución de ella al completo, o de una parte, siempre arrojará los mismos resultados). Ejemplo: PUT y GET sobre el mismo recurso. Además, a veces, un método idempotente como un GET sobre un SCRIPT que modifica el servidor, puede llevar a un comportamiento no idempotente. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 55 6. Códigos de estado y frases de respuesta Los códigos de estado están formados por tres dígitos (xyy). El primero (x) indica el tipo de respuesta y los otros dos (yy) se agrupan para generar 100 posibles razones diferentes en ese grupo. Los códigos de estado válidos van del 100 al 599, ambos inclusive, un código de estado fuera de este rango debe ser tratado como un 5xx (Server Error). Todos los códigos están definidos en el Hypertext Transfer Protocol (HTTP) Status Code Registry del IANA (https://www.iana.org/assignments/http-status- codes/http-status-codes.xhtml). La frase de respuesta es para facilitar la interpretación del código de respuesta por humanos. En el estándar se especifican algunos textos de ejemplo para cada respuesta. Un administrador puede editar estos textos como desee. Las versiones por encima de la HTTP/1.1 ya no envían frase de respuesta. A veces, las respuestas de error pueden contener un recurso HTML donde se muestra el error, y posiblemente información adicional sobre el mismo. En la actualidad es habitual que estén presentes, pero es a discreción del administrador del servidor. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 56 6. Códigos de estado y frases de respuesta Ejemplo de configuración – fichero httpd.conf de Apache # Customizable error responses come in three flavors: # 1) plain text 2) local redirects 3) external redirects # # Some examples: #ErrorDocument 500 "The server has a problem." ErrorDocument 404 /404.html Esta es la opción activa #ErrorDocument 404 "/cgi-bin/missing_handler.pl" #ErrorDocument 402 http://localhost/subscription_info.html # Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 57 6. Códigos de estado y frases de respuesta Códigos de estado – Interpretación del primer dígito FORMATO SIGNIFICADO DESCRIPCIÓN 1yy Mensaje de información Informa de que la petición se ha recibido y el proceso continua o es la respuesta parcial del estado de una conexión. No puede llevar ni contenido, ni trailers. 2yy Éxito El método fue aceptado, comprendido y aceptado por el servidor. 3yy Redirección La petición no ha fallado, pero necesita más información para poder ser completada. 4yy Error de cliente La petición es inválida, tiene una mala sintaxis o no puede ser completada por alguna razón, sin embargo el servidor estima que es un fallo del cliente. 5yy Error de servidor La petición es correcta pero no puede ser completada debido a un fallo del propio servidor. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 58 6. Códigos de estado y frases de respuesta Códigos de estado – Ejemplos CÓDIGO FRASE DESCRIPCIÓN Indica que el servidor ha recibido la parte inicial de la petición y que aún ésta no ha sido 100 Continue rechazada. El servidor intentará enviar una respuesta final cuando la petición haya sido recibida y procesada completamente. Switching El cliente solicita a través de la cabecera Update el uso de un protocolo alternativo y el 101 protocols servidor está de acuerdo. Es la respuesta genérica de operación realizada con éxito. El contenido en una respuesta 200 OK con 200 depende de la petición. La petición ha sido realizada correctamente y como consecuencia se ha creado un nuevo 201 Created recurso. Es la respuesta típica al método PUT cuando el recurso no existía y se crea. El servidor ha completado satisfactoriamente una petición GET parcial que empleó la 206 Partial Content cabecera Range. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 59 6. Códigos de estado y frases de respuesta Códigos de estado – Ejemplos CÓDIGO FRASE DESCRIPCIÓN El recurso solicitado está representado de más de una manera en el servidor. En la 300 Multiple choices respuesta el servidor informa de las diferentes representaciones para que el cliente pueda elegir (parte de la negociación guiada por el cliente). El recurso solicitado ha sido movido permanentemente a una nueva URL. Esta es la 301 Moved Permanently forma apropiada de informar de que un recurso se ha renombrado, y no que se muestre el error 404. El servidor informaría de la nueva ubicación con la cabecera Location. Indica que el recurso reside temporalmente en una URI diferente. Dado que la 302 Found redirección podría ser alterada ocasionalmente, el cliente debería mantener la URI en peticiones futuras. Es una respuesta típica a peticiones condicionales no llevadas a cabo, como cuando el 304 Not Modified cliente envía un GET condicionado para obtener el recurso solamente si ha cambiado. Con este código el servidor no envía de nuevo el recurso al no haber sido modificado. Informa de que el recurso solicitado se ha movido permanentemente a una nueva URI 308 Permanent Redirect con la cabecera Location y en peticiones futuras debería usarse dicha nueva URI. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 60 6. Códigos de estado y frases de respuesta Códigos de estado – Ejemplos CÓDIGO FRASE DESCRIPCIÓN Es una respuesta genérica empleada cuando la petición de cliente no se entiende o no 400 Bad Request se puede llevar a cabo debido a un problema en el lado del cliente. El cliente no está autorizado para acceder a un recurso. Normalmente este es el caso de 401 Unauthorized cuando el recurso está protegido con una clave o por cualquier otro tipo de credenciales. El servidor generará una cabecera WWW-Authenticate en la respuesta. 402 Payment Required Reservado para uso futuro. La petición ha sido entendida por el servidor pero el servidor rechaza el llevarla a cabo. 403 Forbidden En la respuesta el servidor puede describir el motivo de la prohibición. Puede ser una respuesta a una petición de autenticación con información insuficiente. El error más común en HTTP. Se devuelve cuando el servidor no puede encontrar el 404 Not Found recurso solicitado, ya sea porque se ha movido, no existe o el usuario puso mal la URL. El método solicitado no está permitido para ese recurso en concreto. En la respuesta se 405 Method Not Allowed incluye la cabecera Allow que indica los métodos que el servidor permite. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 61 6. Códigos de estado y frases de respuesta Códigos de estado – Ejemplos CÓDIGO FRASE DESCRIPCIÓN Es un mensaje genérico de error que indica que la petición no puede ser completada 500 Internal Server Error debido a un problema inesperado del servidor. El servido no soporta la funcionalidad requerida para llevar a cabo la petición recibida, 501 Not Implemented por lo que no podrá atenderla. El servidor, actuando como proxy o pasarela, recibe una respuesta errónea del otro 502 Bad Gateway servidor que intentó acceder en nombre del cliente. El servidor no podrá atender la petición temporalmente, probablemente debido a que 503 Service Unavailable esté sobrecargado o en mantenimiento. La espera por la respuesta ha expirado cuando el servidor, actuando como proxy o 504 Gateway Timeout pasarela, ha solicitado un recurso de un servidor remoto en nombre del cliente. HTTP Version Not La petición enviada usa una versión de HTTP que el servidor no soporta o reúsa 505 Supported soportar. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 62 7. Cabeceras de HTTP Cabeceras generales Cache-Control: Afecta a cómo se debe tratar una petición o respuesta por cualquier dispositivo en la cadena de peticiones. Prevalecen sobre la configuración de caché establecida en el dispositivo. Existen 7 para peticiones y 10 para respuestas. Pueden verse con más detalle en la RFC 9111. Algunos valores son: no-cache o no-store. Connection: especifica cómo se tratará la conexión, el valor más típico es Close o también Keep-Alive. Upgrade: El cliente informa al servidor de la disponibilidad de otros protocolos de aplicación, pudiendo el servidor acordar el uso de estos. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 63 7. Cabeceras de HTTP Cabeceras generales Transfer-Encoding: Indica el tipo de codificación usada en el cuerpo del mensaje para que no haya errores en la interpretación. Date: fecha y hora en la que se originó el mensaje. Trailer: Complementa el uso del envío de datos en trozos (chunked data). Via: Introducida por los dispositivos que gestionan proxys, pasarelas o túneles para informar al receptor de su presencia. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 64 7. Cabeceras de HTTP Cabeceras de petición Son sólo usadas en las cabeceras de petición HTTP y permiten al cliente: Proporcionar información sobre sí mismo. Aportar detalles sobre la petición que está enviando. Controlar mejor la manera en la que la petición será tratada y respondida. A continuación se verá una breve descripción de algunas de las cabeceras de petición. Otras cabeceras son: Expect, From, If-Match, If-Modified-Since, If- None-Match, If-Range, If-Unmodified-Since, Max-fordwards, Proxy-Authorization, Range, Referer, TE (transfer encodings) o User-Agent. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 65 7. Cabeceras de HTTP Cabeceras de petición Host: Indica el dominio y puerto del host destinatario de la petición. Es la única cabecera de obligatoria presencia en HTTP. En HTTP/2 y HTTP/3 la cabecera host es a veces suplantada por la pseudo- cabecera :authority. Accept: El cliente informa qué tipos de contenido puede soportar. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,**, que simboliza cualquier entidad capaz de ser enviada. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 71 7. Cabeceras de HTTP Tipos y subtipos de contenido Diferencias entre HTTP, MIME y RFC 822 HTTP no incluye la cabecera MIME-Version. La cabecera Content-Encoding tiene una misión diferente en HTTP, indica el tipo de compresión usada, y en MIME indica el formato en el que se representa la información, como BASE64 o ASCII. HTTP no sigue tampoco estrictamente el formato “RFC 822”, ya que permite el envío de entidades en los mensajes HTTP en formato binario, lo cual es más eficiente que codificarlos en BASE64. Así pues, HTTP puede enviar entidades sin ninguna codificación, debiendo ser el cliente quien interprete el contenido a partir de lo que aparezca en la cabecera Content-Type. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 72 7. Cabeceras de HTTP Tipos y subtipos de contenido Esquema de codificación de dos niveles de HTTP Para añadir flexibilidad HTTP aporta: Codificación de contenido: Esta codificación se aplica a la entidad a enviar en un mensaje HTTP Es extremo a extremo. El formato usado se especifica en la cabecera Content-Encoding. El cliente informa de los tipos que soporta con Accept-Encoding. Codificación de transferencia: Su función es asegurar que todo el mensaje se transmite adecuadamente ente dispositivos. Esta codificación se aplica a todo el mensaje HTTP, y no solo a una entidad. La codificación no es extremo a extremo, sino salto a salto. Se informa de la codificación en la cabecera Transfer-Encoding. Normalmente se usa más para identificar el final de mensajes HTTP. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 73 8. Funcionamiento del protocolo HTTP Peticiones condicionales HTTP permite hacer peticiones condicionales en base a una serie de cabeceras. El objetivo principal de estas peticiones es hacer más eficiente la actualización de recursos, ya sea en el cliente como en el servidor. Se basan en la comparación del valor de las etiquetas de entidad generadas para cada recurso (intercambiadas con la cabecera ETag). Comparaciones: If-Match: más empleada con POST, PUT y DELETE, la operación se lleva a cabo si la etiqueta de entidad enviada en la cabecera coincide con la del recurso seleccionado. If-None-Match: principalmente empleada con GET, se realiza la operación si la etiqueta de entidad del recurso no coincide con la enviada en la cabecera. If-Modified-Since: empleada con GET y HEAD, el servidor realiza la operación si la fecha de última actualización del recurso es posterior a la fecha enviada en esta cabecera. If-Unmodified-Since: tiene una función similar a If-Match para cuando no se dispone de una etiqueta de entidad. Igualmente está pensada para POST, PUT y DELETE y la operación se lleva a cabo cuando la fecha aportada en la cabecera es más reciente que la del recurso. If-Range: permite enviar, o una etiqueta de entidad, o una fecha, para obtener el rango deseado si el recurso no ha cambiado (coinciden la etiqueta o la fecha) o el recurso entero si éste ha cambiado. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 74 8. Funcionamiento del protocolo HTTP Negociación de contenido en HTTP Los recursos disponibles a través del protocolo HTTP pueden tener diversos formatos, lenguajes o codificaciones y representar, aún así, la misma información. Así mismo, los agentes de usuario pueden tener diferentes capacidades, características o preferencias para elegir una representación de la información entre todas las disponibles. HTTP aporta mecanismos para que se pueda obtener el recurso que mejor se adapta a las necesidades del cliente (siempre que sea posible). Si a pesar de enviar cabeceras de negociación de contenidos no se pueden satisfacer las necesidades del cliente, un servidor puede enviar en código de estado 406 (Not Acceptable), o enviar un contenido sin tener en cuenta las cabeceras (lo cual no implica que ese contenido pueda ser interpretado por el cliente). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 75 8. Funcionamiento del protocolo HTTP Negociación de contenido en HTTP Existen tres técnicas para la negociación de contenidos: Negociación dirigida por el servidor o proactiva. Negociación dirigida por el cliente o reactiva. Negociación por contenido solicitado: el servidor envía en la respuesta a una petición las cabeceras Accept que estime oportunas para influenciar las subsecuentes peticiones al mismo recurso. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 76 8. Funcionamiento del protocolo HTTP Negociación de contenido en HTTP Negociación dirigida por el servidor Esta es la recomendada y más usada actualmente. Es el servidor, a través de la información aportada por el cliente, quien elige el recurso más apropiado para éste último. Se apoya en las cabeceras de petición: Accept, Accept- Charset, Accept-Encoding, Accept-Language y User-Agent. El servidor usa también la cabecera Vary para informar del criterio usado para la elección del recurso enviado, así como informa a la caché de si esta respuesta es válida para siguientes peticiones. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 77 8. Funcionamiento del protocolo HTTP Negociación de contenido en HTTP Negociación dirigida por el servidor El cliente informa a través de esas cabeceras sus preferencias a través del parámetro ‘q’ de calidad (quality, aunque no tiene relación directa con la calidad real del documento). El valor de q es un número real que va de ‘1’ (máximo), que indica máxima predilección (si se omite q se toma como valor ‘1’), a ‘0.001’ (mínimo) que informa de la mínima predilección. Un valor de 0 informa de la negativa a aceptar ese formato (no aceptable). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 78 8. Funcionamiento del protocolo HTTP Negociación de contenido en HTTP Negociación dirigida por el servidor Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3,de;q=0 Accept: text/*; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c Accept-Charset: iso-8859-5, unicode-1-1; q=0.8 (está obsoleta y no se debe emplear dado que la codificación más común UTF-8 es usada prácticamente en todos los contenidos textuales) Ejemplos Accept-Encoding: compress;q=0.5, gzip;q=1.0 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 Vary: accept-encoding, accept-language Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 79 8. Funcionamiento del protocolo HTTP Negociación de contenido en HTTP Negociación dirigida por el cliente Ante la petición de un recurso disponible en varios formatos el servidor envía una respuesta 300 (múltiples elecciones) con información de las variantes disponibles. El servidor puede devolver el mensaje 406 (No aceptación) si no dispone de una representación del recurso especificado según los criterios del cliente. El cliente envía una nueva petición con el recurso concreto. Es un proceso más selectivo y predecible, pero menos eficiente en cuanto a tiempo y comunicaciones, ya que necesita de dos mensajes extra. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 80 8. Funcionamiento del protocolo HTTP La caché en HTTP La caché es un almacén local (ya sea en el cliente o el servidor) de mensajes previos y un subsistema de HTTP que permite el almacenamiento, la recuperación y el borrado de mensajes en él. El funcionamiento de la caché en HTTP está definida en la RFC 9111 y aunque hoy en día es algo empleado en todos los navegadores, es una característica OPCIONAL de HTTP, aunque manifiestamente deseable. El objetivo fundamental de la caché es reutilizar información ya recibida en respuestas previas para reducir el ancho de banda empleado por una comunicación y el tiempo de respuesta en la obtención de recursos. Una labor también importante de la caché es determinar qué se debe almacenar y qué no. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 81 8. Funcionamiento del protocolo HTTP La caché en HTTP Funcionamiento de la caché Como mínimo, la cache almacena el método y la URI para recuperar una respuesta almacenada previamente (el conjunto de método y URI se denomina cache key). En la actualidad, fundamentalmente, la caché almacena respuestas con código de estado 200 del método GET. Aunque también es posible almacenar respuestas negativas (404 Not found), redirecciones, respuestas incompletas (206 Partial Content) o respuestas a otros métodos diferentes de GET si en su definición se permite el cacheado. La caché debe incluir todas las cabeceras recibidas (incluso las no reconocidas), aunque hay algunas excepciones (como la cabecera Connection, Proxy-Connection, TE, Transfer-Encoding o Upgrade) y otras vinculadas a un proxy (Proxy- Authenticate, Proxy-Authentication-Info y Proxy-Authorization). En posteriores respuestas recibidas, los valores de las cabeceras almacenadas deben ser actualizados (también hay ciertas excepciones como Content-Length). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 82 8. Funcionamiento del protocolo HTTP La caché en HTTP Funcionamiento de la caché Cuando una caché tiene una o más respuestas almacenadas para una URI, pero no puede servir ninguna de ellas, puede emplear el mecanismo de peticiones condicionales. Las respuestas a estas peticiones podrían ser: 304 (Not modified): indica que la respuesta almacenada en la caché puede ser actualizada y reusada. Una respuesta completa: ninguna de las condiciones aportadas era apropiada, por lo que se debe emplear la respuesta completa para satisfacer la petición y podría ser almacenada en la caché. Se recibe un error 5xx: se puede tanto devolver una respuesta almacenada, como repetir la petición condicional. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 83 8. Funcionamiento del protocolo HTTP La caché en HTTP Funcionamiento de la caché Campos de cabecera vinculados con la caché Age: tiempo en segundos que se estima que la respuesta ha estado en una caché desde que dicha respuesta se generó o se validó. Cache-Control: lleva una serie de directivas para controlar el comportamiento de la caché en la cadena de petición/respuesta. Estas directivas son unidireccionales y no tienen por qué ser iguales en la petición que en la respuestas (hay directivas diferentes para peticiones y respuestas). Ejemplos: max-age, no-cache, no-store, public, private, etc. Expires: fecha y hora a partir de la cual una respuesta es considerada obsoleta. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 84 8. Funcionamiento del protocolo HTTP La caché en HTTP Tipos de cachés y problemas funcionales Ubicación de las cachés Cliente de usuario. En un intermediario. Por ejemplo las cachés compartidas, que guardan información de más de un usuario. No se deben almacenar las respuestas marcadas con Cache-Control: private. En el servidor. Problemas: Complejidad añadida al protocolo, clientes y servidores. Necesidad de control de las versiones. Problemas de privacidad: trazabilidad de la actividad o las respuestas almacenadas con cookies. Problemas de seguridad en cachés intermedias. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 85 8. Funcionamiento del protocolo HTTP Seguridad y privacidad en HTTP HTTP es en sí un protocolo no seguro ya que no aporta privacidad de los contenidos por sí mismo aunque sí implementa mecanismos de autenticación: Entran en juego las cabeceras: WWW-Authenticate normalmente en un mensaje de estado 401 (Unauthorized) del servidor o Proxy-Authenticate enviada con el mensaje de estado 407 (Proxy Authentication Required) generado por un proxy. Y Authorization o Proxy-Authorization enviadas por el cliente. En las respuestas a los clientes también se pueden incluir las cabeceras Authentication-Info y Proxy-Authentication-Info, con Información adicional sobre una autenticación correcta. Los mecanismos de autenticación empleados en HTTP se detallan en el Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry del IANA (https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 86 8. Funcionamiento del protocolo HTTP Seguridad y privacidad en HTTP Ejemplos de esquemas de autenticación. Basic [RFC7617]: identificador de usuario y clave separados por “:” y codificado en BASE64. Ejemplo RFC 7617 para userid=“Aladdin” y clave=“open sesame”: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Digest [RFC7616]: basado en resumen de mensaje, se emplea encriptado y algoritmos complejos, pero no es tan fiable como los mecanismos basados en clave pública. Bearer [RFC6750]: empleada en esquemas de autorización con testigos (tokens) como Oauth 2.0. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 87 8. Funcionamiento del protocolo HTTP Seguridad y privacidad en HTTP La seguridad y privacidad en HTTP recaen en otros niveles y en buenas prácticas (en la RFC 9110 se dan algunas de estas recomendaciones): La principal hoy en día: emplear la versión más reciente del protocolo TLS (Transport Layer Security) entre el protocolo de transporte y el de aplicación, que es lo que indica el esquema (scheme) https. No enviar credenciales de cliente en métodos GET, ya que irían en la URI y si se está en un navegador sería publicadas en la barra de dirección o en ficheros de registro en proxys. Encriptado de los recursos. Aparte de que la conexión sea cifrada, cuando el recurso llega al servidor o cliente destino estará desprotegido, por lo que si éste se cifra se le añadirá una nueva capa de seguridad. Un adecuada gestión y administración de los servidores web, como anonimizar los registros de actividad de los servidores (logs). Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 88 8. Funcionamiento del protocolo HTTP Control de estado en HTTP A pesar de sus nuevas versiones, HTTP sigue siendo un protocolo sin estados. Cada nueva petición no tiene en cuenta las peticiones o respuestas que se intercambiaron con anterioridad. Sin embargo, las nuevas aplicaciones web que fueron surgiendo en los años 90 del siglo XX hicieron necesaria la incorporación de un control de estado: Inicialmente propuesto por Netscape ➡️ aparecen las cookies. Publicado por primera vez en 1997 como RFC 2109 “HTTP State Management Mechanism”. Se definen dos nuevas cabeceras: Cookie y Set-Cookie. Actualizado en la RFC 2965 (ahora en la RFC 6265) en el año 2.000: tres cabeceras: Cookie, Cookie2 y Set-Cookie2 (estas dos últimas han quedado obsoletas por la RFC 6265). Problemas: Transmisión de información privada o sensible en una cookie. Uso no deseado. Cookies de terceras partes. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 89 8. Funcionamiento del protocolo HTTP Control de estado en HTTP Funcionamiento Es un proceso iniciado por el servidor: La aplicación de servidor crea una cookie, comunicándola al cliente a través de la cabecera Set-Cookie como un par de nombre/valor. Para establecer varias cookies se deben enviar en cabeceras Set-Cookie por separado. Así pues, en posteriores peticiones al mismo servidor el cliente enviará en la petición la cabecera Cookie con todos los valores que recibió del servidor en anteriores cabeceras Set-Cookie, de manera que éste podrá emplear esta información, por ejemplo, seguir reconociendo al cliente y al proceso que llevaba a cabo (autenticación), establecer valores de configuración o rastrear sus preferencias. Las cookies tienen que tener siempre un nombre (name-value-pair) para identificarlas, y luego pueden tener algún parámetro como los de validez temporal (Expires, Max-Age), el host (Domain) y otros como Path, Secure o HTTPOnly. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 90 8. Funcionamiento del protocolo HTTP Control de estado en HTTP Ejemplo de funcionamiento Establecer una cookie: == Server -> User Agent == Set-Cookie: SID=31d4d96e407aad42 == User Agent -> Server == Cookie: SID=31d4d96e407aad42 Establecer varias cookies: == Server -> User Agent == Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly Set-Cookie: lang=en-US; Path=/; Domain=example.com == User Agent -> Server == Cookie: SID=31d4d96e407aad42; lang=en-US Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 91 8. Funcionamiento del protocolo HTTP Servidores PROXY Se comportan como servidores (para el cliente web) y como clientes (para el servidor web) simultáneamente. Transparentes: no modifican las peticiones del cliente. No transparentes: pueden modificar las peticiones del cliente. Los clientes web deben configurarse específicamente para usar un determinado proxy. Beneficios: Seguridad. Compatibilidad con cachés. Rendimiento. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 92 9. Protocolo HTTP/1.1 Conexiones transitorias y persistentes En las versiones HTTP/0.9 y HTTP/1.0 las conexiones eran transitorias: Una conexión TCP para cada recurso (documento de hipertexto, imagen, clip multimedia, etc.). Esto derivó en un gran desperdicio de recursos conforme los documentos de hipertexto fueron añadiendo enlaces a otros tipo de recursos, tales como imágenes. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 93 9. Protocolo HTTP/1.1 Conexiones transitorias y persistentes Solución de la versión HTTP/1.1: Conexiones persistentes. A través de una misma conexión el cliente puede solicitar todos los recursos necesarios. Se reduce la congestión en la red debida a innecesarios establecimientos de conexión. Se ahorran recursos en los servidores al no tener que mantener tantas conexiones TCP abiertas como antes. Los servidores HTTP/1.1 mantienen las conexiones transitorias para dar soporte a clientes HTTP/0.9 y HTTP/1.0 Un cliente HTTP/1.1 puede especificar su deseo de usar las conexiones transitorias, en vez de las persistentes, enviando la cabecera Connection:Close. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 94 9. Protocolo HTTP/1.1 Pipelining La técnica de pipelining permite el encadenamiento de peticiones HTTP al servidor sin tener que esperar a que las realizadas previamente sean respondidas. Pero se deben responder en orden. Tanto las conexiones persistentes, como el pipelining añaden complejidad al cliente. El cliente tiene que discriminar entre todas las respuestas del servidor qué recurso es el que ha recibido de entre todos los solicitados. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 95 9. Protocolo HTTP/1.1 Establecimiento y gestión de una conexión Conexión TCP al puerto 80 (well known). Otro puerto se puede especificar en la URL. Conexión establecida: se envía la primera petición indicando la versión (0.9, 1.0 o 1.1). Si es 0.9 o 1.0 el servidor usará automáticamente conexiones transitorias. Si es 1.1, las conexiones serán persistentes y se usará el pipelining. Un cliente 1.1 puede desistir de usar las conexiones persistentes, enviando la cabecera en la petición Connection:close. El servidor procesa las peticiones del cliente en orden y le envía las respuestas, en el mismo orden. Si el cliente envía muchas peticiones, los servidores suelen usar el control de flujo de TCP para evitar que envíen más, en vez de cortar la conexión. El cliente recibe las respuestas y muestra al usuario los resultados. Si el cliente ya no va a enviar más peticiones puede indicarlo enviando la cabecera Connection:close en la última que tuviera que enviar. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 96 9. Protocolo HTTP/1.1 Formato general de los mensajes El formato del mensaje HTTP-message sigue la RFC 822 y MIME en gran parte, pero no lo hace estrictamente: HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [ message-body ] Formato: línea inicial campos de cabecera (o cabeceras) del mensaje línea en blanco [cuerpo del mensaje] Las líneas terminan con La línea en blanco es un El cuerpo del mensaje es opcional. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 97 9. Protocolo HTTP/1.1 Formato general de los mensajes Ejemplo de mensajes PETICIÓN GET / HTTP/1.1 Host: www10.ujaen.es User-Agent: Mozilla/5.0 Accept: text/html Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive HTTP/1.1 200 OK Date: Wed, 03 Oct 2012 09:22:10 GMT Server: Apache Content-Length: 6581 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Content-Encoding: gzip RESPUESTA Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 98 9. Protocolo HTTP/1.1 Formato de las peticiones La especificación de la sintaxis de HTTP/1.1 sigue la notación Augmented Backus-Naur Form (ABNF) [RFC 5234]. Están basadas en el formato general antes mostrado: Línea de petición. Cabeceras generales. Cabeceras de petición. Cabeceras de entidad. Línea en blanco. [Cuerpo del mensaje]. Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 99 9. Protocolo HTTP/1.1 Formato de las peticiones Línea de petición request-line = method SP request-target SP HTTP-version Ejemplo: GET /index.html HTTP/1.1 Para completar esta petición, es obligatorio en HTTP/1.1 que siempre esté presente la cabecera Host:. Ejemplo (petición del recurso por defecto): GET / HTTP/1.1 Host: www.ujaen.es Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 100 9. Protocolo HTTP/1.1 Formato de las respuestas Están basadas en el formato general antes mostrado: Línea de estado Cabeceras generales Cabeceras de respuesta Cabeceras de entidad Línea en blanco [cuerpo del mensaje] Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www 101 9. Protocolo HTTP/1.1 Formato de las respuestas Línea de estado status-line = HTTP-version SP status-code SP [reason-phrase] Ejemplo: HTTP/1.1 200 OK Dpto. de Ingeniería de Telecomunicación Universidad de Jaén Versión 4.2.1 Área de Ingeniería Telemática Escuela Politécnica Superior de Linares 2024 Tema 2 Protocolo HTTP y el servicio www
