HTTP ( Protocolo de transferencia de hipertexto ) es un protocolo de capa de aplicación en el modelo de conjunto de protocolos de Internet para sistemas de información hipermedia distribuidos y colaborativos. [1] HTTP es la base de la comunicación de datos para la World Wide Web , donde los documentos de hipertexto incluyen hipervínculos a otros recursos a los que el usuario puede acceder fácilmente, por ejemplo, con un clic del mouse o tocando la pantalla en un navegador web .
El desarrollo de HTTP fue iniciado por Tim Berners-Lee en el CERN en 1989 y resumido en un documento simple que describe el comportamiento de un cliente y un servidor utilizando la primera versión de HTTP, llamada 0.9. [2] Esa versión se desarrolló posteriormente y finalmente se convirtió en la versión pública 1.0. [3]
El desarrollo de las primeras solicitudes de comentarios (RFC) HTTP comenzó unos años más tarde en un esfuerzo coordinado por el Grupo de trabajo de ingeniería de Internet (IETF) y el Consorcio World Wide Web (W3C), y el trabajo se trasladó posteriormente al IETF.
El protocolo HTTP/1 se finalizó y se documentó completamente (como versión 1.0) en 1996. [4] Evolucionó (como versión 1.1) en 1997 y luego sus especificaciones se actualizaron en 1999, 2014 y 2022. [5] Su variante segura denominada HTTPS es utilizada por más del 85% de los sitios web. [6]
HTTP/2 , publicado en 2015, proporciona una expresión más eficiente de la semántica de HTTP "en la red". A partir de agosto de 2024, [update]es compatible con el 66,2 % de los sitios web [7] [8] (35,3 % HTTP/2 + 30,9 % HTTP/3 con compatibilidad con versiones anteriores) y es compatible con casi todos los navegadores web (más del 98 % de los usuarios). [9] También es compatible con los principales servidores web a través de Transport Layer Security (TLS) utilizando una extensión de negociación de protocolo de capa de aplicación (ALPN) [10] donde se requiere TLS 1.2 o más reciente. [11] [12]
HTTP/3 , el sucesor de HTTP/2, se publicó en 2022. [13] A febrero de 2024, [update]ahora se usa en el 30,9% de los sitios web [14] y es compatible con la mayoría de los navegadores web, es decir, (al menos parcialmente) compatible con el 97% de los usuarios. [15] HTTP/3 usa QUIC en lugar de TCP para el protocolo de transporte subyacente. Al igual que HTTP/2, no deja obsoletas las versiones principales anteriores del protocolo. El soporte para HTTP/3 se agregó primero a Cloudflare y Google Chrome , [16] [17] y también está habilitado en Firefox . [18] HTTP/3 tiene una latencia más baja para las páginas web del mundo real, si está habilitado en el servidor, y se carga más rápido que con HTTP/2, en algunos casos más de tres veces más rápido que HTTP/1.1 (que todavía comúnmente solo está habilitado). [19]
HTTP funciona como un protocolo de solicitud-respuesta en el modelo cliente-servidor . Un navegador web , por ejemplo, puede ser el cliente , mientras que un proceso , llamado servidor web , que se ejecuta en una computadora que aloja uno o más sitios web puede ser el servidor . El cliente envía un mensaje de solicitud HTTP al servidor. El servidor, que proporciona recursos como archivos HTML y otro contenido o realiza otras funciones en nombre del cliente, devuelve un mensaje de respuesta al cliente. La respuesta contiene información sobre el estado de finalización de la solicitud y también puede contener el contenido solicitado en el cuerpo del mensaje.
Un navegador web es un ejemplo de un agente de usuario (UA). Otros tipos de agente de usuario incluyen el software de indexación que utilizan los proveedores de búsqueda ( rastreadores web ), los navegadores de voz , las aplicaciones móviles y otro software que accede, consume o muestra contenido web.
El protocolo HTTP está diseñado para permitir que los elementos de red intermedios mejoren o habiliten las comunicaciones entre clientes y servidores. Los sitios web con mucho tráfico suelen beneficiarse de los servidores de caché web que entregan contenido en nombre de los servidores ascendentes para mejorar el tiempo de respuesta. Los navegadores web almacenan en caché los recursos web a los que se accedió anteriormente y los reutilizan, siempre que sea posible, para reducir el tráfico de red. Los servidores proxy HTTP en los límites de la red privada pueden facilitar la comunicación para los clientes sin una dirección enrutable globalmente, al retransmitir mensajes con servidores externos.
Para permitir que los nodos HTTP intermedios (servidores proxy, cachés web, etc.) realicen sus funciones, algunos de los encabezados HTTP (que se encuentran en las solicitudes/respuestas HTTP) se administran salto a salto, mientras que otros encabezados HTTP se administran de extremo a extremo (administrados solo por el cliente de origen y por el servidor web de destino).
HTTP es un protocolo de capa de aplicación diseñado en el marco del conjunto de protocolos de Internet . Su definición presupone un protocolo de capa de transporte subyacente y fiable . [20] En HTTP/3 , el Protocolo de Control de Transmisión (TCP) ya no se utiliza, pero las versiones anteriores siguen siendo más utilizadas y lo más habitual es que utilicen TCP. También se han adaptado para utilizar protocolos no fiables como el Protocolo de Datagramas de Usuario (UDP), sobre el que HTTP/3 también se basa (indirectamente), por ejemplo en HTTPU y el Protocolo Simple de Descubrimiento de Servicios (SSDP).
Los recursos HTTP se identifican y ubican en la red mediante localizadores uniformes de recursos (URL), utilizando los esquemas de identificadores uniformes de recursos (URI) http y https . Como se define en RFC 3986, los URI se codifican como hipervínculos en documentos HTML , de modo de formar documentos de hipertexto interconectados.
En HTTP/1.0 se realiza una conexión TCP independiente al mismo servidor para cada solicitud de recurso. [21]
En cambio, en HTTP/1.1 se puede reutilizar una conexión TCP para realizar múltiples solicitudes de recursos (es decir, páginas HTML, marcos, imágenes, scripts , hojas de estilo , etc.). [22] [23]
Por lo tanto, las comunicaciones HTTP/1.1 experimentan menos latencia ya que el establecimiento de conexiones TCP presenta una sobrecarga considerable, especialmente en condiciones de alto tráfico. [24]
HTTP/2 es una revisión del anterior HTTP/1.1 con el fin de mantener el mismo modelo cliente-servidor y los mismos métodos de protocolo pero con estas diferencias en orden:
Por lo tanto, las comunicaciones HTTP/2 experimentan mucha menos latencia y, en la mayoría de los casos, velocidades incluso mayores que las comunicaciones HTTP/1.1.
HTTP/3 es una revisión del anterior HTTP/2 para utilizar los protocolos de transporte QUIC + UDP en lugar de TCP. Antes de esa versión, se utilizaban conexiones TCP/IP; pero ahora, sólo se utiliza la capa IP (sobre la que se basa UDP, al igual que TCP). Esto mejora ligeramente la velocidad media de las comunicaciones y evita el problema ocasional (muy raro) de congestión de la conexión TCP que puede bloquear o ralentizar temporalmente el flujo de datos de todos sus flujos (otra forma de " bloqueo de cabecera de línea ").
El término hipertexto fue acuñado por Ted Nelson en 1965 en el Proyecto Xanadu , que a su vez se inspiró en la visión de Vannevar Bush de los años 30 del sistema de recuperación y gestión de información basado en microfilmes " memex " descrito en su ensayo de 1945 " As We May Think ". A Tim Berners-Lee y su equipo del CERN se les atribuye la invención del HTTP original, junto con HTML y la tecnología asociada para un servidor web y una interfaz de usuario cliente llamada navegador web . Berners-Lee diseñó el HTTP para ayudar a la adopción de su otra idea: el proyecto "WorldWideWeb", que se propuso por primera vez en 1989, ahora conocido como World Wide Web .
El primer servidor web se puso en marcha en 1990. [26] [27] El protocolo utilizado tenía un solo método, concretamente GET, que solicitaba una página a un servidor. [28] La respuesta del servidor siempre era una página HTML. [2]
En 1991, la primera versión oficial documentada de HTTP se escribió como un documento simple, de menos de 700 palabras, y esta versión se denominó HTTP/0.9, que solo admitía el método GET, lo que permitía a los clientes recuperar únicamente documentos HTML del servidor, pero no admitía ningún otro formato de archivo ni carga de información. [2]
Desde 1992, se escribió un nuevo documento para especificar la evolución del protocolo básico hacia su próxima versión completa. Admitía tanto el método de solicitud simple de la versión 0.9 como la solicitud GET completa que incluía la versión HTTP del cliente. Este fue el primero de los muchos borradores no oficiales de HTTP/1.0 que precedieron al trabajo final sobre HTTP/1.0. [3]
Después de haber decidido que se requerían nuevas características del protocolo HTTP y que debían ser completamente documentadas como RFC oficiales , a principios de 1995 se constituyó el HTTP Working Group (HTTP WG, liderado por Dave Raggett ) con el objetivo de estandarizar y expandir el protocolo con operaciones extendidas, negociación extendida, metainformación más rica, ligada con un protocolo de seguridad que se volviera más eficiente al agregar métodos adicionales y campos de encabezado . [29] [30]
El GT HTTP planeó revisar y publicar nuevas versiones del protocolo como HTTP/1.0 y HTTP/1.1 en 1995, pero, debido a las numerosas revisiones, ese plazo duró mucho más de un año. [31]
El GT HTTP también planeó especificar una versión mucho más futura de HTTP llamada HTTP-NG (HTTP Next Generation) que habría resuelto todos los problemas restantes de las versiones anteriores relacionados con el rendimiento, las respuestas de baja latencia, etc., pero este trabajo comenzó solo unos años después y nunca se completó.
En mayo de 1996, se publicó el RFC 1945 como una revisión final de HTTP/1.0 de lo que se había utilizado en los cuatro años anteriores como borrador pre-estándar HTTP/1.0 que ya utilizaban muchos navegadores y servidores web.
A principios de 1996, los desarrolladores comenzaron a incluir extensiones no oficiales del protocolo HTTP/1.0 (es decir, conexiones de mantenimiento de conexión, etc.) en sus productos mediante el uso de borradores de las futuras especificaciones HTTP/1.1. [32]
Desde principios de 1996, los principales desarrolladores de navegadores y servidores web también comenzaron a implementar nuevas características especificadas en las especificaciones preliminares del estándar HTTP/1.1. La adopción por parte de los usuarios finales de las nuevas versiones de navegadores y servidores fue rápida. En marzo de 1996, una empresa de alojamiento web informó que más del 40% de los navegadores en uso en Internet utilizaban el nuevo encabezado HTTP/1.1 "Host" para habilitar el alojamiento virtual y que, en junio de 1996, el 65% de todos los navegadores que accedían a sus servidores eran compatibles con el estándar HTTP/1.1 anterior. [33]
En enero de 1997, RFC 2068 se publicó oficialmente como especificaciones HTTP/1.1.
En junio de 1999, se publicó el RFC 2616 para incluir todas las mejoras y actualizaciones basadas en las especificaciones HTTP/1.1 anteriores (obsoletas).
En 1997, retomando el plan de 1995 del anterior HTTP Working Group, se formó un HTTP-NG Working Group para desarrollar un nuevo protocolo HTTP llamado HTTP-NG (HTTP New Generation). Se elaboraron algunas propuestas/borradores para que el nuevo protocolo utilizara la multiplexación de transacciones HTTP dentro de una única conexión TCP/IP, pero en 1999, el grupo interrumpió su actividad y pasó los problemas técnicos al IETF. [34]
En 2007, el Grupo de Trabajo HTTP del IETF (HTTP WG bis o HTTPbis) se reinició, primero para revisar y aclarar las especificaciones HTTP/1.1 anteriores y, segundo, para escribir y refinar las futuras especificaciones HTTP/2 (llamadas httpbis). [35] [36]
En 2009, Google , una empresa privada, anunció que había desarrollado y probado un nuevo protocolo binario HTTP llamado SPDY . El objetivo implícito era acelerar enormemente el tráfico web (especialmente entre los futuros navegadores web y sus servidores).
De hecho, SPDY fue mucho más rápido que HTTP/1.1 en muchas pruebas, por lo que fue rápidamente adoptado por Chromium y luego por otros navegadores web importantes. [37]
Algunas de las ideas sobre la multiplexación de flujos HTTP a través de una única conexión TCP/IP fueron tomadas de varias fuentes, incluido el trabajo del Grupo de Trabajo HTTP-NG del W3C.
En enero-marzo de 2012, el Grupo de Trabajo HTTP (HTTPbis) anunció la necesidad de comenzar a centrarse en un nuevo protocolo HTTP/2 (mientras finalizaba la revisión de las especificaciones HTTP/1.1), tal vez tomando en consideración las ideas y el trabajo realizado para SPDY. [38] [39]
Después de unos meses de pensar qué hacer para desarrollar una nueva versión de HTTP, se decidió derivarla de SPDY. [40]
En mayo de 2015, HTTP/2 se publicó como RFC 7540 y fue rápidamente adoptado por todos los navegadores web que ya soportaban SPDY y, más lentamente, por los servidores web.
En junio de 2014, el Grupo de Trabajo HTTP publicó una especificación HTTP/1.1 actualizada de seis partes, dejando obsoleta la RFC 2616:
En el Apéndice A del RFC 7230, se desaprobó el protocolo HTTP/0.9 para los servidores que admiten la versión HTTP/1.1 (y superiores): [41]
Dado que HTTP/0.9 no admitía campos de encabezado en una solicitud, no existe ningún mecanismo para que admita hosts virtuales basados en nombres (selección de recursos mediante la inspección del campo de encabezado Host). Cualquier servidor que implemente hosts virtuales basados en nombres debería deshabilitar la compatibilidad con HTTP/0.9 . La mayoría de las solicitudes que parecen ser HTTP/0.9 son, de hecho, solicitudes HTTP/1.x mal construidas causadas por un cliente que no codificó correctamente el destino de la solicitud.
Desde 2016, muchos administradores de productos y desarrolladores de agentes de usuario (navegadores, etc.) y servidores web han comenzado a planificar la eliminación gradual y el desuso del soporte para el protocolo HTTP/0.9, principalmente por las siguientes razones: [42]
[nota 2]
En 2020, se publicaron los primeros borradores de HTTP/3 y los principales navegadores y servidores web comenzaron a adoptarlo.
El 6 de junio de 2022, IETF estandarizó HTTP/3 como RFC 9114. [43]
En junio de 2022, se publicó un lote de RFC que dejó obsoletos muchos de los documentos anteriores e introdujo algunos cambios menores y una refactorización de la descripción de la semántica HTTP en un documento separado.
HTTP es un protocolo de nivel de aplicación sin estado y requiere una conexión de transporte de red confiable para intercambiar datos entre el cliente y el servidor. [20] En las implementaciones de HTTP, se utilizan conexiones TCP/IP utilizando puertos conocidos (normalmente el puerto 80 si la conexión no está cifrada o el puerto 443 si la conexión está cifrada, consulte también Lista de números de puerto TCP y UDP ). [44] [45] En HTTP/2, se utiliza una conexión TCP/IP más múltiples canales de protocolo. En HTTP/3, se utiliza el protocolo de transporte de aplicaciones QUIC sobre UDP.
Los datos se intercambian a través de una secuencia de mensajes de solicitud-respuesta que se intercambian mediante una conexión de transporte de capa de sesión . [20] Un cliente HTTP intenta inicialmente conectarse a un servidor estableciendo una conexión (real o virtual). Un servidor HTTP(S) que escucha en ese puerto acepta la conexión y luego espera un mensaje de solicitud del cliente. El cliente envía su mensaje de solicitud HTTP. Al recibir la solicitud, el servidor envía un mensaje de respuesta HTTP, que incluye encabezado(s) más un cuerpo si es necesario. El cuerpo de este mensaje de respuesta es típicamente el recurso solicitado, aunque también se puede devolver un mensaje de error u otra información. En cualquier momento (por muchas razones) el cliente o el servidor pueden cerrar la conexión. El cierre de una conexión generalmente se anuncia con anticipación mediante el uso de uno o más encabezados HTTP en el último mensaje de solicitud/respuesta enviado al servidor o al cliente. [22]
En HTTP/0.9 , la conexión TCP/IP siempre se cierra después de enviar la respuesta del servidor, por lo que nunca es persistente.
En HTTP/1.0 , como se indica en RFC 1945, el servidor siempre debe cerrar la conexión TCP/IP después de enviar una respuesta. [nota 3]
En HTTP/1.1 se introdujo oficialmente un mecanismo de mantenimiento de la conexión para que una conexión pudiera reutilizarse para más de una solicitud/respuesta. Estas conexiones persistentes reducen la latencia de la solicitud de forma perceptible porque el cliente no necesita renegociar la conexión TCP 3-Way-Handshake después de que se haya enviado la primera solicitud. Otro efecto secundario positivo es que, en general, la conexión se vuelve más rápida con el tiempo debido al mecanismo de inicio lento de TCP .
HTTP/1.1 agregó también la canalización HTTP para reducir aún más el tiempo de retraso al usar conexiones persistentes al permitir que los clientes envíen múltiples solicitudes antes de esperar cada respuesta. Esta optimización nunca se consideró realmente segura porque algunos servidores web y muchos servidores proxy , especialmente servidores proxy transparentes ubicados en Internet / Intranets entre clientes y servidores, no manejaban las solicitudes canalizadas correctamente (servían solo la primera solicitud descartando las otras, cerraban la conexión porque veían más datos después de la primera solicitud o algunos servidores proxy incluso devolvían respuestas fuera de orden, etc.). Debido a esto, solo las solicitudes HEAD y algunas GET (es decir, limitadas a solicitudes de archivos reales y, por lo tanto, con URL sin cadena de consulta utilizada como comando, etc.) podían canalizarse en un modo seguro e idempotente. Después de muchos años de luchar con los problemas introducidos por la habilitación de la canalización, esta característica primero se deshabilitó y luego se eliminó de la mayoría de los navegadores también debido a la adopción anunciada de HTTP/2.
HTTP/2 amplió el uso de conexiones persistentes al multiplexar muchas solicitudes/respuestas simultáneas a través de una única conexión TCP/IP.
HTTP/3 no utiliza conexiones TCP/IP sino QUIC + UDP (ver también: descripción técnica).
"Content-Length: number"no estaba presente en los encabezados HTTP y el cliente asumía que, cuando el servidor cerraba la conexión, el contenido se había enviado en su totalidad. Este mecanismo no podía distinguir entre una transferencia de recursos completada con éxito y una interrumpida (debido a un error del servidor o de la red, o por cualquier otra razón).HTTP proporciona múltiples esquemas de autenticación, como la autenticación de acceso básico y la autenticación de acceso resumido , que funcionan a través de un mecanismo de desafío-respuesta mediante el cual el servidor identifica y emite un desafío antes de servir el contenido solicitado.
HTTP proporciona un marco general para el control de acceso y la autenticación, a través de un conjunto extensible de esquemas de autenticación de desafío-respuesta, que pueden ser utilizados por un servidor para desafiar una solicitud de cliente y por un cliente para proporcionar información de autenticación. [1]
Los mecanismos de autenticación descritos anteriormente pertenecen al protocolo HTTP y son administrados por el software HTTP del cliente y del servidor (si está configurado para requerir autenticación antes de permitir el acceso del cliente a uno o más recursos web), y no por las aplicaciones web que utilizan una sesión de aplicación web.
La especificación de autenticación HTTP también proporciona una construcción arbitraria y específica de la implementación para dividir aún más los recursos comunes a una URI raíz determinada . La cadena de valores de dominio, si está presente, se combina con la URI raíz canónica para formar el componente de espacio de protección del desafío. Esto, en efecto, permite que el servidor defina ámbitos de autenticación separados bajo una URI raíz. [1]
HTTP es un protocolo sin estado . Un protocolo sin estado no requiere que el servidor web conserve información o estado sobre cada usuario durante la duración de varias solicitudes.
Algunas aplicaciones web necesitan administrar sesiones de usuario, por lo que implementan estados o sesiones del lado del servidor , utilizando por ejemplo cookies HTTP [46] o variables ocultas dentro de formularios web .
Para iniciar una sesión de usuario en una aplicación, se debe realizar una autenticación interactiva mediante el inicio de sesión en la aplicación web. Para finalizar una sesión de usuario, el usuario debe solicitar una operación de cierre de sesión . Este tipo de operaciones no utilizan autenticación HTTP, sino una autenticación de aplicación web personalizada y administrada.
Los mensajes de solicitud son enviados por un cliente a un servidor de destino. [nota 4]
Un cliente envía mensajes de solicitud al servidor, que consisten en: [47]
OBTENER /images/logo.png HTTP / 1.1Anfitrión: www.example.comAceptar idioma: es
En el protocolo HTTP/1.1, todos los campos de encabezado excepto Host: hostnameson opcionales.
Los servidores aceptan una línea de solicitud que contiene solo el nombre de la ruta para mantener la compatibilidad con los clientes HTTP antes de la especificación HTTP/1.0 en RFC 1945. [48]
HTTP define métodos (a veces denominados verbos , pero en ninguna parte de la especificación se menciona verbo ) para indicar la acción deseada que se realizará en el recurso identificado. Lo que este recurso representa, ya sean datos preexistentes o datos que se generan dinámicamente, depende de la implementación del servidor. A menudo, el recurso corresponde a un archivo o la salida de un ejecutable que reside en el servidor. La especificación HTTP/1.0 [49] definió los métodos GET, HEAD y POST, así como también enumeró los métodos PUT, DELETE, LINK y UNLINK bajo métodos adicionales. Sin embargo, la especificación HTTP/1.1 [50] definió y agregó formalmente cinco métodos nuevos: PUT, DELETE, CONNECT, OPTIONS y TRACE. Cualquier cliente puede usar cualquier método y el servidor puede configurarse para admitir cualquier combinación de métodos. Si un método es desconocido para un intermediario, se tratará como un método inseguro y no idempotente . No hay límite para la cantidad de métodos que se pueden definir, lo que permite especificar métodos futuros sin afectar la infraestructura existente. Por ejemplo, WebDAV definió siete métodos nuevos y RFC 5789 especificó el método PATCH .
Los nombres de los métodos distinguen entre mayúsculas y minúsculas. [51] [52] Esto contrasta con los nombres de los campos del encabezado HTTP que no distinguen entre mayúsculas y minúsculas. [53]
Content-Length).Todos los servidores web de propósito general deben implementar al menos los métodos GET y HEAD, y la especificación considera que todos los demás métodos son opcionales. [52]
Un método de solicitud es seguro si una solicitud con ese método no tiene ningún efecto deseado en el servidor. Los métodos GET, HEAD, OPTIONS y TRACE se definen como seguros. En otras palabras, los métodos seguros están pensados para ser de solo lectura . Los métodos seguros pueden tener efectos secundarios que el cliente no ve, como agregar información de la solicitud a un archivo de registro o cobrar una cuenta de publicidad .
Por el contrario, los métodos POST, PUT, DELETE, CONNECT y PATCH no son seguros. Pueden modificar el estado del servidor o tener otros efectos, como el envío de un correo electrónico . Por lo tanto, los robots o rastreadores web que cumplen con las normas no suelen utilizar dichos métodos ; algunos de los que no cumplen con las normas tienden a realizar solicitudes sin tener en cuenta el contexto ni las consecuencias.
A pesar de la seguridad prescrita de las solicitudes GET, en la práctica su manejo por parte del servidor no está técnicamente limitado de ninguna manera. Una programación descuidada o deliberadamente irregular puede permitir que las solicitudes GET provoquen cambios no triviales en el servidor. Esto se desaconseja debido a los problemas que pueden ocurrir cuando el almacenamiento en caché web , los motores de búsqueda y otros agentes automatizados realizan cambios no deseados en el servidor. Por ejemplo, un sitio web puede permitir la eliminación de un recurso a través de una URL como https://example.com/article/1234/delete , que, si se obtiene arbitrariamente, incluso utilizando GET, simplemente eliminaría el artículo. [60] Un sitio web codificado correctamente requeriría un método DELETE o POST para esta acción, que los bots no maliciosos no harían.
Un ejemplo de esto en la práctica fue la versión beta de Google Web Accelerator , que precargaba URL arbitrarias en la página que estaba viendo el usuario, lo que provocaba que los registros se modificaran o eliminaran automáticamente en masa . La versión beta se suspendió solo unas semanas después de su primer lanzamiento, tras críticas generalizadas. [61] [60]
Un método de solicitud es idempotente si varias solicitudes idénticas con ese método tienen el mismo efecto que una sola solicitud de ese tipo. Los métodos PUT y DELETE, y los métodos seguros se definen como idempotentes. Los métodos seguros son trivialmente idempotentes, ya que están destinados a no tener ningún efecto en el servidor; los métodos PUT y DELETE, por su parte, son idempotentes ya que las solicitudes idénticas sucesivas serán ignoradas. Un sitio web podría, por ejemplo, configurar un punto final PUT para modificar la dirección de correo electrónico registrada de un usuario. Si este punto final está configurado correctamente, cualquier solicitud que solicite cambiar la dirección de correo electrónico de un usuario a la misma dirección de correo electrónico que ya está registrada (por ejemplo, solicitudes duplicadas después de una solicitud exitosa) no tendrá efecto. De manera similar, una solicitud para ELIMINAR un determinado usuario no tendrá efecto si ese usuario ya ha sido eliminado.
Por el contrario, los métodos POST, CONNECT y PATCH no son necesariamente idempotentes y, por lo tanto, enviar una solicitud POST idéntica varias veces puede modificar aún más el estado del servidor o tener más efectos, como enviar varios correos electrónicos . En algunos casos, este es el efecto deseado, pero en otros casos puede ocurrir accidentalmente. Un usuario podría, por ejemplo, enviar inadvertidamente varias solicitudes POST al hacer clic en un botón nuevamente si no se le dio una respuesta clara de que se estaba procesando el primer clic. Si bien los navegadores web pueden mostrar cuadros de diálogo de alerta para advertir a los usuarios en algunos casos en los que volver a cargar una página puede volver a enviar una solicitud POST, generalmente depende de la aplicación web manejar los casos en los que una solicitud POST no debe enviarse más de una vez.
Tenga en cuenta que el protocolo o el servidor web no determinan si un método es idempotente o no. Es perfectamente posible escribir una aplicación web en la que (por ejemplo) una inserción de base de datos u otra acción no idempotente se active mediante una solicitud GET u otra. Sin embargo, hacerlo en contra de las recomendaciones puede tener consecuencias indeseables si un agente de usuario supone que repetir la misma solicitud es seguro cuando no lo es.
Un método de solicitud se puede almacenar en caché si las respuestas a las solicitudes con ese método se pueden almacenar para su posterior reutilización. Los métodos GET, HEAD y POST se definen como almacenables en caché.
Por el contrario, los métodos PUT, DELETE, CONNECT, OPTIONS, TRACE y PATCH no se pueden almacenar en caché.
Los campos de encabezado de solicitud permiten al cliente pasar información adicional más allá de la línea de solicitud, actuando como modificadores de solicitud (de manera similar a los parámetros de un procedimiento). Brindan información sobre el cliente, sobre el recurso de destino o sobre el manejo esperado de la solicitud.
Un servidor envía un mensaje de respuesta a un cliente como respuesta a su mensaje de solicitud anterior. [nota 4]
Un servidor envía mensajes de respuesta al cliente, que consisten en: [47]
HTTP / 1.1 200 OKTipo de contenido: texto/htmlEn HTTP/1.0 y posteriores, la primera línea de la respuesta HTTP se denomina línea de estado e incluye un código de estado numérico (como " 404 ") y una frase textual de motivo (como "No encontrado"). El código de estado de respuesta es un código entero de tres dígitos que representa el resultado del intento del servidor de comprender y satisfacer la solicitud correspondiente del cliente. La forma en que el cliente maneja la respuesta depende principalmente del código de estado y, en segundo lugar, de los demás campos del encabezado de respuesta. Es posible que los clientes no comprendan todos los códigos de estado registrados, pero deben comprender su clase (dada por el primer dígito del código de estado) y tratar un código de estado no reconocido como equivalente al código de estado x00 de esa clase.
Las frases de motivo estándar son solo recomendaciones y pueden reemplazarse con "equivalentes locales" a discreción del desarrollador web . Si el código de estado indica un problema, el agente de usuario puede mostrar la frase de motivo al usuario para proporcionar más información sobre la naturaleza del problema. El estándar también permite que el agente de usuario intente interpretar la frase de motivo , aunque esto puede ser imprudente ya que el estándar especifica explícitamente que los códigos de estado son legibles por máquina y las frases de motivo son legibles por humanos.
El primer dígito del código de estado define su clase:
1XX(informativo)2XX(exitoso)3XX(redirección)4XX(error del cliente)5XX(error del servidor)Los campos del encabezado de respuesta permiten que el servidor pase información adicional más allá de la línea de estado, actuando como modificadores de respuesta. Proporcionan información sobre el servidor o sobre el acceso posterior al recurso de destino o a recursos relacionados.
Cada campo de encabezado de respuesta tiene un significado definido que puede refinarse aún más mediante la semántica del método de solicitud o el código de estado de respuesta.
A continuación se muestra un ejemplo de transacción HTTP entre un cliente HTTP/1.1 y un servidor HTTP/1.1 que se ejecuta en www.example.com , puerto 80. [nota 5] [nota 6]
GET / HTTP / 1.1 Host : www.example.com Agente de usuario : Mozilla/5.0 Aceptación : text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Aceptación de idioma : en-GB,en;q=0.5 Aceptación de codificación : gzip, deflate, br Conexión : keep-aliveUna solicitud de cliente (que en este caso consta de la línea de solicitud y algunos encabezados que se pueden reducir a solo el "Host: hostname"encabezado) va seguida de una línea en blanco, de modo que la solicitud termina con un doble final de línea, cada uno en forma de retorno de carro seguido de un avance de línea . El "Host: hostname"valor del encabezado distingue entre varios nombres DNS que comparten una única dirección IP , lo que permite el alojamiento virtual basado en nombres . Si bien es opcional en HTTP/1.0, es obligatorio en HTTP/1.1. (Una "/" (barra) generalmente obtendrá un archivo /index.html si lo hay).
HTTP / 1.1 200 OK Fecha : lunes, 23 de mayo de 2005 22:38:34 GMT Tipo de contenido : text/html; charset=UTF-8 Longitud del contenido : 155 Última modificación : miércoles, 08 de enero de 2003 23:11:55 GMT Servidor : Apache/1.3.3.7 (Unix) (Red-Hat/Linux) ETag : "3f80f-1b6-3e1cb03b" Rangos de aceptación : bytes Conexión : cerrada< html > < head > < title > Una página de ejemplo </ title > </ head > < body > < p > Hola mundo, este es un documento HTML muy simple. </ p > </ body > </ html >El campo de encabezado ETag (etiqueta de entidad) se utiliza para determinar si una versión en caché del recurso solicitado es idéntica a la versión actual del recurso en el servidor. "Content-Type"especifica el tipo de medio de Internet de los datos transmitidos por el mensaje HTTP, mientras que "Content-Length"indica su longitud en bytes. El servidor web HTTP/1.1 publica su capacidad para responder a solicitudes de ciertos rangos de bytes del documento configurando el campo . Esto es útil si el cliente necesita que el servidor envíe "Accept-Ranges: bytes"solo ciertas partes [62] de un recurso, lo que se denomina servicio de bytes . Cuando "Connection: close"se envía, significa que el servidor web cerrará la conexión TCP inmediatamente después del final de la transferencia de esta respuesta. [22]
La mayoría de las líneas de encabezado son opcionales, pero algunas son obligatorias. Cuando "Content-Length: number"falta el encabezado en una respuesta con un cuerpo de entidad, esto se debe considerar un error en HTTP/1.0, pero puede que no sea un error en HTTP/1.1 si el encabezado "Transfer-Encoding: chunked"está presente. La codificación de transferencia fragmentada utiliza un tamaño de fragmento de 0 para marcar el final del contenido. Algunas implementaciones antiguas de HTTP/1.0 omitían el encabezado "Content-Length"cuando no se conocía la longitud de la entidad del cuerpo al comienzo de la respuesta y, por lo tanto, la transferencia de datos al cliente continuaba hasta que el servidor cerraba el socket.
Se puede utilizar para informar al cliente que la parte de la entidad del cuerpo de los datos transmitidos está comprimida por el algoritmo gzip."Content-Encoding: gzip"
La forma más popular de establecer una conexión HTTP cifrada es HTTPS . [63] También existen otros dos métodos para establecer una conexión HTTP cifrada: el Protocolo de transferencia de hipertexto seguro y el uso del encabezado de actualización HTTP/1.1 para especificar una actualización a TLS. Sin embargo, el soporte del navegador para estos dos es casi inexistente. [64] [65] [66]
Esto reduce la barrera para implementar TLS 1.3, una importante mejora de seguridad con respecto a TLS 1.2.
Un error común es utilizar GET para una acción que actualiza un recurso. [...] Este problema salió a la luz pública en Rails en 2005, cuando se lanzó Google Web Accelerator.
