HTTP
Protocolo de aplicación para sistemas de información hipermedia distribuidos y colaborativos

HTTP
Norma internacional
  • RFC  1945 HTTP/1.0
  • RFC  9110 Semántica HTTP
  • RFC  9111 Almacenamiento en caché HTTP
  • RFC  9112 HTTP/1.1
  • RFC  9113 HTTP/2
  • RFC  7541 HTTP/2: Compresión de encabezado HPACK
  • RFC  8164 HTTP/2: Seguridad oportunista para HTTP/2
  • RFC  8336 HTTP/2: El marco HTTP/2 ORIGIN
  • RFC  8441 HTTP/2: Arranque de WebSockets con HTTP/2
  • RFC  9114 HTTP/3
  • RFC  9204 HTTP/3: QPACK: Compresión de campos
Desarrollado porInicialmente CERN ; IETF , W3C
Introducido1991 ; hace 33 años ( 1991 )
Sitio webhttps://httpwg.org/specs/
HTTP
Métodos de solicitud
  • OPCIONES
  • CONSEGUIR
  • CABEZA
  • CORREO
  • PONER
  • BORRAR
  • RASTRO
  • CONECTAR
  • PARCHE
Campos de encabezado
Response status codes
Security access control methods
Security vulnerabilities
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

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]

Descripción técnica

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 la última versión 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 (indirectamente) siempre se construye, 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:

  • utilizar una representación binaria comprimida de metadatos (encabezados HTTP) en lugar de una textual, de modo que los encabezados requieran mucho menos espacio;
  • utilizar una única conexión TCP/IP (normalmente encriptada ) por dominio de servidor al que se acceda en lugar de 2 a 8 conexiones TCP/IP;
  • utilizar uno o más flujos bidireccionales por conexión TCP/IP en el que las solicitudes y respuestas HTTP se descomponen y transmiten en paquetes pequeños para casi resolver el problema del HOLB ( bloqueo de cabecera de línea ). [nota 1]
  • para agregar una capacidad de envío para permitir que la aplicación del servidor envíe datos a los clientes siempre que haya nuevos datos disponibles (sin forzar a los clientes a solicitar periódicamente nuevos datos al servidor mediante métodos de sondeo ). [25]

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 ").

Historia

Tim Berners-Lee

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]

Resumen de versiones de hitos HTTP

VersiónAño de introducciónEstado actualUso en agosto de 2024[update]Soporte en agosto de 2024[update]
HTTP/0.91991Obsoleto0100%
HTTP/1.01996Obsoleto0100%
HTTP/1.11997Estándar33,8%100%
HTTP/22015Estándar35,3%66,2%
HTTP/32022Estándar30,9%30,9%

HTTP/0.9

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]

Borrador HTTP/1.0

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]

Grupo de trabajo HTTP del W3C

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ó.

HTTP/1.0

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]

HTTP/1.1

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).

Grupo de trabajo HTTP-NG del W3C

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]

Se reinicia el grupo de trabajo HTTP de la IETF

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]

SPDY: un protocolo HTTP no oficial desarrollado por Google

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.

HTTP/2

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.

Actualizaciones de 2014 a HTTP/1.1

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:

  • RFC  7230, HTTP/1.1: Sintaxis y enrutamiento de mensajes
  • RFC  7231, HTTP/1.1: Semántica y contenido
  • RFC  7232, HTTP/1.1: Solicitudes condicionales
  • RFC  7233, HTTP/1.1: Solicitudes de rango
  • RFC  7234, HTTP/1.1: Almacenamiento en caché
  • RFC  7235, HTTP/1.1: Autenticación

Desuso de HTTP/0.9

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]

  • Es tan simple que nunca se escribió un documento RFC (sólo existe el documento original); [2]
  • no tiene encabezados HTTP y carece de muchas otras características que hoy en día son necesarias por razones de seguridad mínimas;
  • No se ha generalizado desde 1999-2000 (debido a HTTP/1.0 y HTTP/1.1) y comúnmente solo lo usan algunos equipos de red muy antiguos, es decir, enrutadores , etc.

[nota 2]

HTTP/3

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]

Actualizaciones y refactorizaciones en 2022

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.

  • RFC  9110, Semántica HTTP
  • RFC  9111, almacenamiento en caché HTTP
  • RFC  9112, HTTP/1.1
  • RFC  9113, HTTP/2
  • RFC  9114, HTTP/3 (ver también la sección anterior)
  • RFC  9204, QPACK: Compresión de campos para HTTP/3
  • RFC  9218, Esquema de priorización extensible para HTTP

Intercambio de datos HTTP

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.

Mensajes de solicitud y respuesta a través de conexiones

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]

Conexiones persistentes

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 se pudiera reutilizar una conexión 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).

Optimizaciones de recuperación de contenido

HTTP/0.9
Un recurso solicitado siempre fue enviado en su totalidad.
HTTP/1.0
HTTP/1.0 agregó encabezados para administrar los recursos almacenados en caché por el cliente con el fin de permitir solicitudes GET condicionales; en la práctica, un servidor debe devolver el contenido completo del recurso solicitado solo si el cliente no conoce la fecha de su última modificación o si cambió desde la última respuesta completa a la solicitud GET. Uno de estos encabezados, "Content-Encoding", se agregó para especificar si el contenido devuelto de un recurso estaba comprimido o no .
Si no se conocía de antemano la longitud total del contenido de un recurso (es decir, porque se generó dinámicamente, etc.), el encabezado "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/1.1
Se introdujo HTTP/1.1:
  • Nuevos encabezados para administrar mejor la recuperación condicional de recursos almacenados en caché.
  • codificación de transferencia fragmentada para permitir que el contenido se transmita en fragmentos para enviarlo de manera confiable incluso cuando el servidor no conoce su longitud de antemano (es decir, porque se genera dinámicamente, etc.).
  • servicio de rango de bytes , donde un cliente puede solicitar solo una o más porciones (rangos de bytes) de un recurso (es decir, la primera parte, una parte en el medio o al final de todo el contenido, etc.) y el servidor generalmente envía solo la(s) parte(s) solicitada(s). Esto es útil para reanudar una descarga interrumpida (cuando un archivo es muy grande), cuando solo se debe mostrar una parte de un contenido o agregarla dinámicamente a la parte ya visible por un navegador (es decir, solo el primero o los siguientes n comentarios de una página web) para ahorrar tiempo, ancho de banda y recursos del sistema, etc.
HTTP/2, HTTP/3
Tanto HTTP/2 como HTTP/3 han mantenido las características mencionadas anteriormente de HTTP/1.1.

Autenticación HTTP

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.

Ámbitos de autenticación

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]

Sesión de aplicación HTTP

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.

Mensajes de solicitud HTTP/1.1

Los mensajes de solicitud son enviados por un cliente a un servidor de destino. [nota 4]

Sintaxis de la solicitud

Un cliente envía mensajes de solicitud al servidor, que consisten en: [47]

  • una línea de solicitud , que consta del método de solicitud que distingue entre mayúsculas y minúsculas, un espacio , la URI solicitada, otro espacio, la versión del protocolo, un retorno de carro y un avance de línea , por ejemplo:
OBTENER  /images/logo.png  HTTP / 1.1
  • cero o más campos de encabezado de solicitud (al menos 1 o más encabezados en el caso de HTTP/1.1), cada uno compuesto por el nombre del campo sin distinción entre mayúsculas y minúsculas, dos puntos, un espacio inicial opcional , el valor del campo, un espacio final opcional y finalizando con un retorno de carro y un avance de línea, por ejemplo:
Anfitrión: www.example.comAceptar idioma: es
  • una línea vacía, que consta de un retorno de carro y un avance de línea;
  • un cuerpo de mensaje opcional .

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]

Métodos de solicitud

Una solicitud HTTP/1.1 realizada mediante Telnet. El mensaje de solicitud , la sección de encabezado de respuesta y el cuerpo de la respuesta están resaltados.

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]

CONSEGUIR
El método GET solicita que el recurso de destino transfiera una representación de su estado. Las solicitudes GET solo deben recuperar datos y no deben tener ningún otro efecto. (Esto también es cierto para algunos otros métodos HTTP). [1] Para recuperar recursos sin realizar cambios, se prefiere GET sobre POST, ya que se puede acceder a ellos a través de una URL . Esto permite marcar y compartir y hace que las respuestas GET sean aptas para el almacenamiento en caché , lo que puede ahorrar ancho de banda. El W3C ha publicado principios de orientación sobre esta distinción, diciendo: " El diseño de aplicaciones web debe estar informado por los principios anteriores, pero también por las limitaciones relevantes". [54] Vea los métodos seguros a continuación.

CABEZA
El método HEAD solicita que el recurso de destino transfiera una representación de su estado, como en el caso de una solicitud GET, pero sin los datos de representación incluidos en el cuerpo de la respuesta. Esto resulta útil para recuperar los metadatos de representación en el encabezado de respuesta, sin tener que transferir la representación completa. Los usos incluyen comprobar si una página está disponible a través del código de estado y encontrar rápidamente el tamaño de un archivo ( Content-Length).

CORREO
El método POST solicita que el recurso de destino procese la representación incluida en la solicitud de acuerdo con la semántica del recurso de destino. Por ejemplo, se utiliza para publicar un mensaje en un foro de Internet , suscribirse a una lista de correo o completar una transacción de compra en línea . [55]

PONER
El método PUT solicita que el recurso de destino cree o actualice su estado con el estado definido por la representación incluida en la solicitud. Una distinción con respecto a POST es que el cliente especifica la ubicación del destino en el servidor. [56]

BORRAR
El método DELETE solicita que el recurso de destino elimine su estado.

CONECTAR
El método CONNECT solicita que el intermediario establezca un túnel TCP/IP hacia el servidor de origen identificado por el destino de la solicitud. Se suele utilizar para proteger conexiones a través de uno o más servidores proxy HTTP con TLS . [57] [58] Véase el método HTTP CONNECT .

OPCIONES
El método OPTIONS solicita que el recurso de destino transfiera los métodos HTTP que admite. Esto se puede utilizar para comprobar la funcionalidad de un servidor web solicitando "*" en lugar de un recurso específico.

RASTRO
El método TRACE solicita que el recurso de destino transfiera la solicitud recibida en el cuerpo de la respuesta. De esa manera, un cliente puede ver qué cambios o adiciones (si los hay) han realizado los intermediarios.

PARCHE
El método PATCH solicita que el recurso de destino modifique su estado de acuerdo con la actualización parcial definida en la representación incluida en la solicitud. Esto puede ahorrar ancho de banda al actualizar una parte de un archivo o documento sin tener que transferirlo en su totalidad. [59]

Todos los servidores web de propósito general deben implementar al menos los métodos GET y HEAD, y todos los demás métodos se consideran opcionales según la especificación. [52]

Propiedades de los métodos de solicitud
Método de solicitudSolicitud de cotizaciónLa solicitud tiene un cuerpo de carga útilLa respuesta tiene un cuerpo de carga útilSeguroIdempotenteAlmacenable en caché
CONSEGUIRRFC  9110OpcionalSíSíSíSí
CABEZARFC  9110OpcionalNoSíSíSí
CORREORFC  9110SíSíNoNoSí
PONERRFC  9110SíSíNoSíNo
BORRARRFC  9110OpcionalSíNoSíNo
CONECTARRFC  9110OpcionalSíNoNoNo
OPCIONESRFC  9110OpcionalSíSíSíNo
RASTRORFC  9110NoSíSíSíNo
PARCHERFC  5789SíSíNoNoNo

Métodos seguros

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]

Métodos idempotentes

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.

Métodos almacenables en caché

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é.

Campos del encabezado de la solicitud

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.

Mensajes de respuesta HTTP/1.1

Un servidor envía un mensaje de respuesta a un cliente como respuesta a su mensaje de solicitud anterior. [nota 4]

Sintaxis de respuesta

Un servidor envía mensajes de respuesta al cliente, que consisten en: [47]

  • una línea de estado , que consta de la versión del protocolo, un espacio , el código de estado de respuesta , otro espacio, una frase de motivo posiblemente vacía, un retorno de carro y un avance de línea , por ejemplo:
    HTTP / 1.1  200  OK
  • cero o más campos de encabezado de respuesta , cada uno compuesto por el nombre del campo sin distinción entre mayúsculas y minúsculas, dos puntos, un espacio inicial opcional , el valor del campo, un espacio final opcional y finalizando con un retorno de carro y un avance de línea, por ejemplo:
    Tipo de contenido: texto/html
  • una línea vacía, que consta de un retorno de carro y un avance de línea;
  • un cuerpo de mensaje opcional .

Códigos de estado de respuesta

En 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)
Se recibió la solicitud, continuando el proceso.
2XX(exitoso)
La solicitud fue recibida, entendida y aceptada exitosamente.
3XX(redirección)
Es necesario realizar más acciones para completar la solicitud.
4XX(error del cliente)
La solicitud contiene una sintaxis incorrecta o no se puede cumplir.
5XX(error del servidor)
El servidor no pudo cumplir una solicitud aparentemente válida.

Campos del encabezado de respuesta

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.

Ejemplo de transacción de solicitud/respuesta HTTP/1.1

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]

Solicitud del cliente

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-alive

Una 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).

Respuesta del servidor

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"

Conexiones cifradas

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]

Protocolos similares

  • El protocolo Gopher es un protocolo de distribución de contenidos que fue reemplazado por HTTP a principios de la década de 1990.
  • El protocolo SPDY es una alternativa a HTTP desarrollada en Google , reemplazada por HTTP/2 .
  • El protocolo Gemini es un protocolo inspirado en Gopher que exige características relacionadas con la privacidad.

Véase también

HTTP
Request methods
Header fields
Response status codes
Security access control methods
Security vulnerabilities

Notas

  1. ^ En la práctica, estos flujos se utilizan como múltiples subconexiones TCP/IP para multiplexar solicitudes/respuestas simultáneas, lo que reduce en gran medida la cantidad de conexiones TCP/IP reales en el lado del servidor, de 2 a 8 por cliente a 1, y permite atender a muchos más clientes a la vez.
  2. ^ En 2022, la compatibilidad con HTTP/0.9 no ha quedado oficialmente obsoleta por completo y todavía está presente en muchos servidores web y navegadores (solo para respuestas de servidor), aunque normalmente está deshabilitada. No está claro cuánto tiempo llevará descontinuar HTTP/0.9.
  3. ^ Desde finales de 1996, algunos desarrolladores de navegadores y servidores HTTP/1.0 populares (especialmente aquellos que habían planeado también dar soporte a HTTP/1.1) comenzaron a implementar (como una extensión no oficial) una especie de mecanismo de mantenimiento de la conexión (mediante el uso de nuevos encabezados HTTP) para mantener abierta la conexión TCP/IP para más de un par de solicitud/respuesta y así acelerar el intercambio de múltiples solicitudes/respuestas. [32]
  4. ^ ab HTTP/2 y HTTP/3 tienen una representación diferente para los métodos y encabezados HTTP.
  5. ^ HTTP/1.0 tiene los mismos mensajes excepto algunos encabezados faltantes.
  6. ^ HTTP/2 y HTTP/3 utilizan el mismo mecanismo de solicitud/respuesta pero con diferentes representaciones para los encabezados HTTP.

Referencias

  1. ^ abcd Fielding, R.; Nottingham, M.; Reschke, J. (junio de 2022). Semántica HTTP. IETF. doi : 10.17487/RFC9110 . RFC 9110.
  2. ^ abcd Tim Berner-Lee (1 de enero de 1991). "El HTTP original tal como se definió en 1991". www.w3.org . Consorcio World Wide Web . Consultado el 24 de julio de 2010 .
  3. ^ por Tim Berner-Lee (1992). "HTTP básico tal como se definió en 1992". www.w3.org . Consorcio World Wide Web . Consultado el 19 de octubre de 2021 .
  4. ^ En RFC  1945. Esa especificación fue luego superada por HTTP/1.1.
  5. ^ El RFC  2068 (1997) quedó obsoleto por el RFC  2616 en 1999, que quedó obsoleto por el RFC  7230 en 2014, que quedó obsoleto por el RFC  9110 en 2022.
  6. ^ "Estadísticas de uso del protocolo predeterminado https para sitios web". w3techs.com . Consultado el 5 de enero de 2024 .
  7. ^ "Estadísticas de uso de HTTP/2 para sitios web". w3techs.com . Consultado el 5 de enero de 2024 .
  8. ^ "Estadísticas de uso de HTTP/3 para sitios web, agosto de 2024". w3techs.com . Consultado el 13 de agosto de 2024 .
  9. ^ "¿Puedo usar... Tablas de soporte para HTML5, CSS3, etc."? caniuse.com . Consultado el 5 de enero de 2024 .
  10. ^ Friedl, S.; Popov, A.; Langley, A.; Stephan, E. (julio de 2014). Extensión de negociación del protocolo de capa de aplicación de seguridad de la capa de transporte (TLS). IETF. doi : 10.17487/RFC7301 . RFC 7301.
  11. ^ Belshe, M.; Peon, R.; Thomson, M. "Protocolo de transferencia de hipertexto versión 2, uso de funciones TLS". Archivado desde el original el 15 de julio de 2013. Consultado el 10 de febrero de 2015 .
  12. ^ Benjamin, David. Uso de TLS 1.3 con HTTP/2. doi : 10.17487/RFC8740 . RFC 8740 . Consultado el 2 de junio de 2020 . Esto reduce la barrera para implementar TLS 1.3, una importante mejora de seguridad con respecto a TLS 1.2.
  13. ^ HTTP/3. 6 de junio de 2022. doi : 10.17487/RFC9114 . RFC 9114. Consultado el 6 de junio de 2022 .
  14. ^ "Estadísticas de uso de HTTP/3 para sitios web". w3techs.com . Consultado el 8 de enero de 2024 .
  15. ^ "¿Puedo usar... Tablas de soporte para HTML5, CSS3, etc."? canIuse.com . Consultado el 8 de enero de 2024 .
  16. ^ Cimpanu, Catalin (26 de septiembre de 2019). «Cloudflare, Google Chrome y Firefox añaden compatibilidad con HTTP/3». ZDNet . Consultado el 27 de septiembre de 2019 .
  17. ^ "HTTP/3: el pasado, el presente y el futuro". El blog de Cloudflare . 26 de septiembre de 2019 . Consultado el 30 de octubre de 2019 .
  18. ^ "Firefox Nightly es compatible con HTTP 3 – General – Comunidad Cloudflare". 2019-11-19 . Consultado el 2020-01-23 .
  19. ^ "HTTP/3 es rápido". Métricas de solicitud . Consultado el 1 de julio de 2022 .
  20. ^ abc "Conexiones, clientes y servidores". RFC 9110, Semántica HTTP. sec. 3.3. doi : 10.17487/RFC9110 . RFC 9110.
  21. ^ "Operación general". RFC 1945. págs. 6–8. sec. 1.3. doi : 10.17487/RFC1945 . RFC 1945.
  22. ^ abc "Gestión de la conexión: establecimiento". RFC 9112, HTTP/1.1. sec. 9.1. doi : 10.17487/RFC9112 . RFC 9112.
  23. ^ "Gestión de conexiones: persistencia". RFC 9112, HTTP/1.1. sec. 9.3. doi : 10.17487/RFC9112 . RFC 9112.
  24. ^ "Documentos HTTP clásicos". W3.org. 14 de mayo de 1998. Consultado el 1 de agosto de 2010 .
  25. ^ "Descripción general del protocolo HTTP/2". RFC 9113, HTTP/2). sec. 2. doi : 10.17487/RFC7540 . RFC 7540.
  26. ^ "Invención de la Web, Historia de la Web, Quién inventó la Web, Tim Berners-Lee, Robert Cailliau, CERN, Primer servidor web". LivingInternet . Consultado el 11 de agosto de 2021 .
  27. ^ Berners-Lee, Tim (2 de octubre de 1990). «daemon.c: servidor basado en TCP/IP para hipertexto». www.w3.org . Consultado el 11 de agosto de 2021 .
  28. ^ Berners-Lee, Tim. "Protocolo de transferencia de hipertexto". World Wide Web Consortium . Consultado el 31 de agosto de 2010 .
  29. ^ Raggett, Dave. "Biografía de Dave Raggett". Consorcio World Wide Web . Consultado el 11 de junio de 2010 .
  30. ^ Raggett, Dave; Berners-Lee, Tim. "Grupo de trabajo sobre protocolo de transferencia de hipertexto". Consorcio World Wide Web . Consultado el 29 de septiembre de 2010 .
  31. ^ Raggett, Dave. "Planes del grupo de trabajo HTTP". World Wide Web Consortium . Consultado el 29 de septiembre de 2010 .
  32. ^ de David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: La guía definitiva. (extracto del capítulo: "Conexiones persistentes"). O'Reilly Media, Inc. ISBN 9781565925090. Recuperado el 18 de octubre de 2021 .
  33. ^ "Navegadores compatibles con HTTP 1.1". webcom.com . Archivado desde el original el 4 de febrero de 1998. Consultado el 29 de mayo de 2009 .
  34. ^ "Grupo de trabajo HTTP-NG". www.w3.org . Consorcio World Wide Web. 1997 . Consultado el 19 de octubre de 2021 .
  35. ^ Web Administrator (2007). "Grupo de trabajo HTTP". httpwg.org . IETF . Consultado el 19 de octubre de 2021 .
  36. ^ ab Web Administrator (2007). "Grupo de trabajo HTTP: estatuto httpbis". datatracker.ietf.org . IETF . Consultado el 19 de octubre de 2021 .
  37. ^ "SPDY: Un protocolo experimental para una web más rápida". dev.chromium.org . Google. 2009-11-01 . Consultado el 2021-10-19 .
  38. ^ "Rechartering httpbis". IETF; HTTP WG. 2012-01-24 . Consultado el 2021-10-19 .
  39. ^ Secretario del IESG (19 de marzo de 2012). "Acción del grupo de trabajo: RECHARTER: Protocolo de transferencia de hipertexto Bis (httpbis)". IETF; Grupo de trabajo sobre HTTP . Consultado el 19 de octubre de 2021 .
  40. ^ Ilya Grigorik; Surma (3 de septiembre de 2019). "Redes de navegadores de alto rendimiento: Introducción a HTTP/2". developer.google.com . Google Inc . Consultado el 19 de octubre de 2021 .
  41. ^ "Apéndice A: Historial de versiones de HTTP". RFC 7230, HTTP/1.1: Sintaxis de mensajes y enrutamiento. pág. 78. sec. A. doi : 10.17487/RFC7230 . RFC 7230.
  42. ^ Matt Menke (30 de junio de 2016). "Intención de descontinuar y eliminar: compatibilidad con HTTP/0.9". groups.google.com . Consultado el 15 de octubre de 2021 .
  43. ^ HTTP/3. 6 de junio de 2022. doi : 10.17487/RFC9114 . RFC 9114. Consultado el 6 de junio de 2022 .
  44. ^ "Esquema de URI http". RFC 9110, Semántica HTTP. sec. 4.2.1. doi : 10.17487/RFC9110 . RFC 9110.
  45. ^ "Esquema de URI https". RFC 9110, Semántica HTTP. sec. 4.2.2. doi : 10.17487/RFC9110 . RFC 9110.
  46. ^ Lee, Wei-Bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (25 de enero de 2019). "Protección segura y eficiente para cookies HTTP con autoverificación". Revista internacional de sistemas de comunicación . 32 (2): e3857. doi :10.1002/dac.3857. S2CID  59524143.
  47. ^ ab "Formato de mensaje". RFC 9112: HTTP/1.1. sec. 2.1. doi : 10.17487/RFC9112 . RFC 9112.
  48. ^ "Semana Apache. HTTP/1.1". Archivado desde el original el 2021-06-02 . Consultado el 2021-05-03 .090502 apacheweek.com
  49. ^ Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk. "Definiciones de métodos". Protocolo de transferencia de hipertexto – HTTP/1.0. IETF. págs. 30–32. sec. 8. doi : 10.17487/RFC1945 . RFC 1945.
  50. ^ "Definiciones de métodos". RFC 2616. págs. 51–57. sección 9. doi : 10.17487/RFC2616 . RFC 2616.
  51. ^ "Línea de solicitud". RFC 9112, HTTP/1.1. sec. 3. doi : 10.17487/RFC9112 . RFC 9112.
  52. ^ ab "Métodos: descripción general". RFC 9110, Semántica HTTP. sec. 9.1. doi : 10.17487/RFC9110 . RFC 9110.
  53. ^ "Campos de encabezado". RFC 9110, Semántica HTTP. sección 6.3. doi : 10.17487/RFC9110 . RFC 9110.
  54. ^ Jacobs, Ian (2004). "URIs, Addressability, and the use of HTTP GET and POST". Conclusiones del Technical Architecture Group . W3C . Consultado el 26 de septiembre de 2010 .
  55. ^ "POST". RFC 9110, Semántica HTTP. sec. 9.3.3. doi : 10.17487/RFC9110 . RFC 9110.
  56. ^ "PUT". RFC 9110, Semántica HTTP. sección 9.3.4. doi : 10.17487/RFC9110 . RFC 9110.
  57. ^ "CONECTAR". RFC 9110, Semántica HTTP. sec. 9.3.6. doi : 10.17487/RFC9110 . RFC 9110.
  58. ^ "Nota de vulnerabilidad VU#150227: Las configuraciones predeterminadas del proxy HTTP permiten conexiones TCP arbitrarias". US-CERT . 2002-05-17 . Consultado el 2007-05-10 .
  59. ^ Dusseault, Lisa; Snell, James M. (marzo de 2010). Método PATCH para HTTP. IETF. doi : 10.17487/RFC5789 . RFC 5789.
  60. ^ ab Ediger, Brad (21 de diciembre de 2007). Advanced Rails: creación de aplicaciones web de nivel industrial en tiempo récord. O'Reilly Media, Inc., pág. 188. ISBN 978-0596519728Un 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 .
  61. ^ Cantrell, Christian (1 de junio de 2005). "¿Qué hemos aprendido del acelerador web de Google?". Adobe Blogs . Adobe. Archivado desde el original el 19 de agosto de 2017 . Consultado el 19 de noviembre de 2018 .
  62. ^ Luotonen, Ari; Franks, John (22 de febrero de 1996). Extensión de recuperación de rango de bytes para HTTP. IETF. ID draft-ietf-http-range-retrieval-00.
  63. ^ Canavan, John (2001). Fundamentos de seguridad de redes . Norwood, MA: Artech House. págs. 82-83. ISBN 9781580531764.
  64. ^ Zalewski, Michal. "Manual de seguridad del navegador" . Consultado el 30 de abril de 2015 .
  65. ^ "Chromium Issue 4527: implement RFC 2817: Upgrading to TLS Within HTTP/1.1" (Edición 4527 de Chromium: implementación de RFC 2817: actualización a TLS dentro de HTTP/1.1) . Consultado el 30 de abril de 2015 .
  66. ^ "Error de Mozilla 276813 – [RFE] Soporte RFC 2817 / Actualización de TLS para HTTP 1.1" . Consultado el 30 de abril de 2015 .
  67. ^ Nottingham, Mark (octubre de 2010). Enlaces web. IETF. doi : 10.17487/RFC5988 . RFC 5988.
Wikilibros tiene un libro sobre el tema: Redes de comunicación/Protocolo HTTP
Wikimedia Commons tiene medios relacionados con Protocolo de transferencia de hipertexto .
  • Sitio web oficial
  • Grupo de trabajo HTTP de la IETF en GitHub
  • "Historial de cambios para HTTP". W3.org . Consultado el 1 de agosto de 2010 .Una historia técnica detallada de HTTP.
  • "Cuestiones de diseño para HTTP". W3.org . Consultado el 1 de agosto de 2010 .Problemas de diseño de Berners-Lee cuando estaba diseñando el protocolo.


Retrieved from "https://en.wikipedia.org/w/index.php?title=HTTP&oldid=1250568137"