Hispanopedia Wiki
Articulo de referencia

HTTP

Comprobado HTTP ( Protocolo de Transferencia de Hipertexto ) es un protocolo de capa de aplicación en el conjunto de protocolos de Internet para sistemas de información hipermed...

Hispanopedia WikiContenido en espanolLectura gratuita
Comprobado
Página protegida con cambios pendientes

HTTP ( Protocolo de Transferencia de Hipertexto ) es un protocolo de capa de aplicación en el 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, haciendo clic con el ratón o tocando la pantalla en un navegador web .

HTTP es un protocolo de solicitud-respuesta en el modelo cliente-servidor . Una transacción comienza cuando un cliente envía una solicitud al servidor, el servidor intenta satisfacer la solicitud y devuelve una respuesta al cliente que describe el resultado de la solicitud y, opcionalmente, contiene un recurso solicitado, como un documento HTML u otro contenido.

En un escenario común, un navegador web actúa como cliente y un servidor web , que aloja uno o más sitios web , como servidor . Un navegador web es un ejemplo de agente de usuario (AU). Otros tipos de agentes de usuario incluyen el software de indexación utilizado por los proveedores de búsqueda ( rastreadores web ), navegadores de voz , aplicaciones móviles y otro software que accede, consume o muestra contenido web.

HTTP está diseñado para permitir que los elementos de red intermedios mejoren o faciliten la comunicación entre clientes y servidores. Los sitios web con mucho tráfico suelen beneficiarse de servidores de caché web que entregan contenido en nombre de los servidores de origen para mejorar el tiempo de respuesta. Los navegadores web almacenan en caché los recursos web a los que se ha accedido previamente y los reutilizan, siempre que sea posible, para reducir el tráfico de red. Los servidores proxy HTTP en los límites de las redes privadas pueden facilitar la comunicación para clientes sin una dirección enrutable globalmente, reenviando los mensajes a servidores externos.

Para permitir que los nodos HTTP intermedios (servidores proxy, cachés web, etc.) cumplan sus funciones, algunos de los encabezados HTTP (que se encuentran en las solicitudes/respuestas HTTP) se gestionan salto a salto, mientras que otros encabezados HTTP se gestionan de extremo a extremo (gestionados únicamente por el cliente de origen y por el servidor web de destino).

Un recurso web se localiza mediante un localizador uniforme de recursos (URL), utilizando los esquemas de identificador uniforme de recursos (URI) http y https . Los URI se codifican como hipervínculos en documentos HTML , para formar documentos de hipertexto interconectados . [ 2 ]

Versiones

El protocolo se ha revisado con el tiempo. Cada versión se identifica como HTTP/#, donde # es el número de versión. Este artículo abarca aspectos de todas las versiones, pero se centra principalmente en HTTP/0.9, HTTP/1.0 y HTTP/1.1. Existen artículos aparte que tratan en detalle HTTP/2 y HTTP/3 .

En HTTP/1.0, se establece una conexión TCP independiente con el mismo servidor para cada solicitud de recurso. [ 3 ] : §1.3

En HTTP/1.1, en cambio, una conexión TCP puede reutilizarse para realizar múltiples solicitudes de recursos (es decir, de páginas HTML, marcos, imágenes, scripts , hojas de estilo , etc.). [ 4 ] : §9.1,9.3 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. [ 5 ]

Las mejoras añadidas con HTTP/2 permiten una menor latencia y, en la mayoría de los casos, velocidades más altas que las comunicaciones HTTP/1.1. HTTP/2 añade compatibilidad con:

  • una representación binaria comprimida de los metadatos (encabezados HTTP) en lugar de una representación textual, de modo que los encabezados requieren mucho menos espacio;
  • una única conexión TCP/IP (normalmente cifrada ) por dominio de servidor al que se accede, en lugar de entre 2 y 8 conexiones TCP/IP;
  • uno o más flujos bidireccionales por conexión TCP/IP en los que las solicitudes y respuestas HTTP se dividen y se transmiten en pequeños paquetes para casi resolver el problema del HOLB ( bloqueo de cabecera de línea ); [ nota 1 ]
  • una capacidad de envío que permite a la aplicación del servidor enviar datos a los clientes cuando hay nuevos datos disponibles (sin obligar a los clientes a solicitar periódicamente nuevos datos al servidor mediante métodos de sondeo ). [ 6 ] : §2

HTTP/3 utiliza los protocolos de transporte QUIC + UDP en lugar de TCP. Solo se utiliza la capa IP (sobre la cual se basa UDP, al igual que TCP). Esto mejora ligeramente la velocidad promedio de las comunicaciones y evita el problema ocasional de la congestión de la conexión TCP , que puede bloquear o ralentizar temporalmente el flujo de datos de todas sus transmisiones (otra forma de " bloqueo de cabecera de cola ").

Usar

HTTP/2 es compatible con el 71% de los sitios web [ 7 ] [ 8 ] (34,1% HTTP/2 + 36,9% HTTP/3 con retrocompatibilidad) y 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) mediante una extensión Application-Layer Protocol Negotiation (ALPN) [ 10 ] donde se requiere TLS 1.2 o posterior. [ 6 ]

HTTP/3 se utiliza en el 36,9 % de los sitios web [ 11 ] y es compatible con la mayoría de los navegadores web, es decir, (al menos parcialmente) con el 97 % de los usuarios. [ 12 ] HTTP/3 utiliza QUIC en lugar de TCP como protocolo de transporte subyacente. Al igual que HTTP/2, no deja obsoletas las versiones principales anteriores del protocolo. En 2019, se añadió compatibilidad con HTTP/3 a Cloudflare y Chrome [ 13 ] [ 14 ] y también se habilitó en Firefox . [ 15 ] HTTP/3 tiene una latencia menor para páginas web reales y carga más rápido que HTTP/2, en algunos casos más de tres veces más rápido que HTTP/1.1, que sigue siendo comúnmente el único protocolo habilitado. [ 16 ]

HTTPS , la variante segura de HTTP, es utilizada por más del 85% de los sitios web. [ 17 ]

Tecnología

capa de transporte

HTTP presupone un protocolo de capa de transporte subyacente y confiable . [ 18 ] : §3.3 La elección estándar del protocolo subyacente antes de HTTP/3 es el Protocolo de Control de Transmisión (TCP). HTTP/3 utiliza una capa de transporte diferente llamada QUIC , que proporciona confiabilidad sobre el Protocolo de Datagramas de Usuario (UDP) no confiable. HTTP/1.1 y anteriores se han adaptado para usarse sobre UDP simple no confiable en situaciones de multidifusión y unidifusión , formando HTTPMU y HTTPU. Se utilizan en UPnP y Protocolo Simple de Descubrimiento de Servicios (SSDP), dos protocolos que generalmente se ejecutan en una red de área local .

Intercambio de datos

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. [ 19 ] En las implementaciones de HTTP, se utilizan conexiones TCP/IP usando puertos conocidos (normalmente el puerto 80 si la conexión no está cifrada o el puerto 443 si la conexión está cifrada, ver también Lista de números de puerto TCP y UDP ). [ 18 ] : §4.2.1,4.2.2 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 aplicación QUIC sobre UDP.

Mensajes de solicitud y respuesta a través de conexiones

Los datos se intercambian mediante una secuencia de mensajes de solicitud-respuesta que se intercambian a través de una conexión de transporte de capa de sesión . [ 19 ] Un cliente HTTP intenta inicialmente establecer una conexión, real o virtual, con un servidor. Un servidor HTTP que escucha en el puerto acepta la conexión y luego espera el 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 encabezados y un cuerpo si es necesario. El cuerpo de este mensaje de respuesta suele ser el recurso solicitado, aunque también puede devolverse un mensaje de error u otra información. En cualquier momento y por muchas razones, tanto el cliente como el servidor pueden cerrar la conexión. El cierre de una conexión generalmente se anuncia mediante uno o más encabezados HTTP en la última solicitud o respuesta. [ 4 ] : §9.1

Conexiones persistentes

En HTTP/0.9, la conexión TCP/IP siempre se cierra después de que se ha enviado la respuesta del servidor, por lo que nunca es persistente.

En HTTP/1.0, el servidor siempre debe cerrar la conexión TCP/IP después de que se haya enviado una respuesta. [ 3 ] [ nota 2 ]

En HTTP/1.1, se introdujo oficialmente un mecanismo de mantenimiento de conexión (keep-alive) para que una conexión pudiera reutilizarse para más de una solicitud/respuesta. Estas conexiones persistentes reducen notablemente la latencia de las solicitudes , ya que el cliente no necesita renegociar la conexión TCP de tres vías tras el envío de la primera solicitud. Otro efecto secundario positivo es que, en general, la conexión se vuelve más rápida con el tiempo gracias al mecanismo de inicio lento de TCP .

HTTP/1.1 también añadió la canalización HTTP para reducir aún más el tiempo de latencia al usar conexiones persistentes, permitiendo a los clientes enviar 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 los servidores proxy transparentes ubicados en Internet/ Intranets entre clientes y servidores, no manejaban correctamente las solicitudes canalizadas (solo atendían la primera solicitud descartando las demás, cerraban la conexión porque veían más datos después de la primera solicitud o algunos proxies 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 usada como comando, etc.) podían canalizarse de forma segura e idempotente . Después de muchos años lidiando con los problemas introducidos al habilitar la canalización, esta función primero se deshabilitó y luego se eliminó de la mayoría de los navegadores. La canalización también se eliminó 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.

Optimización de la recuperación de contenido

En HTTP/0.9, el recurso solicitado siempre se enviaba en su totalidad.

HTTP/1.0 añadió encabezados para gestionar los recursos almacenados en caché por un cliente con el fin de permitir solicitudes GET condicionales.

  • Un servidor debe devolver el contenido completo del recurso solicitado solo si el cliente desconoce su hora de última modificación o si esta ha cambiado desde la última respuesta completa a una solicitud GET.
  • Content-EncodingSe agregó un encabezado para especificar si el contenido devuelto está comprimido .
  • Si el tamaño del contenido no se conoce de antemano (por ejemplo, porque se genera dinámicamente), noContent-Length se incluirá la cabecera. El cliente asumiría que la transferencia se completó al cerrarse la conexión, pero un cierre prematuro dejaría al cliente con contenido parcial sin que este lo supiera.

HTTP/1.1 se introdujo y las versiones posteriores ofrecen:

  • Encabezados para gestionar mejor la recuperación condicional de recursos almacenados en caché.
  • La función de entrega de rangos de bytes permite que un cliente solicite porciones (rangos de bytes) de un recurso. Esto resulta útil para reanudar una descarga interrumpida (cuando un archivo es muy grande), cuando solo se debe mostrar una parte del contenido o agregarlo dinámicamente a la parte ya visible del navegador (por ejemplo, solo los primeros o los siguientes n comentarios de una página web) para ahorrar tiempo, ancho de banda y recursos del sistema, etc.

Sesión de solicitud

Como protocolo sin estado , HTTP no requiere que el servidor web conserve información o estado sobre cada usuario durante la duración de múltiples solicitudes. Si una aplicación web necesita una sesión de aplicación , la implementa a través de cookies HTTP , [ 21 ] variables ocultas en un formulario web u otro mecanismo.

Normalmente, para iniciar una sesión se realiza un inicio de sesión interactivo, y para finalizarla, el usuario solicita cerrar la sesión. Este tipo de operaciones utiliza un mecanismo de autenticación personalizado , no la autenticación HTTP .

Autenticación

HTTP proporciona varios esquemas de autenticación, como la autenticación de acceso básico y la autenticación de acceso digest , que funcionan mediante un mecanismo de desafío-respuesta, en el que 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 un servidor puede utilizar para desafiar una solicitud del cliente y un cliente para proporcionar información de autenticación. [ 18 ]

Los mecanismos de autenticación descritos anteriormente pertenecen al protocolo HTTP y son gestionados 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 .

La especificación de autenticación HTTP incluye dominios que proporcionan una estructura arbitraria y específica de la implementación para subdividir aún más los recursos comunes a una URI raíz determinada . La cadena de valor del 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 permite, en efecto, que el servidor defina ámbitos de autenticación separados bajo una misma URI raíz. [ 1 ]

Conexión cifrada

La forma más popular de establecer una conexión HTTP cifrada es HTTPS . [ 22 ] También existen otros dos métodos para establecer una conexión HTTP cifrada: el Protocolo de Transferencia de Hipertexto Seguro ( HTTP ) y el uso del encabezado HTTP/1.1 Upgrade para especificar una actualización a TLS. Sin embargo, la compatibilidad de los navegadores con estos dos métodos es prácticamente inexistente. [ 23 ] [ 24 ] [ 25 ]

Formato del mensaje

Solicitud HTTP/1.1 realizada mediante telnet. Las partes de la transacción se muestran en diferentes colores: la solicitud en rojo, el encabezado de respuesta en morado y el cuerpo de la respuesta en verde.

Esta sección describe los mensajes para HTTP/1.1. Las versiones posteriores, HTTP/2 [ 26 ] y HTTP/3 , utilizan un protocolo binario , donde las cabeceras se codifican en una sola trama HEADERSy cero o más CONTINUATIONtramas utilizando HPACK [ 27 ] (HTTP/2) o QPACK (HTTP/3), que proporcionan una compresión de cabecera eficiente. La línea de solicitud o respuesta de HTTP/1 también se ha reemplazado por varios campos de pseudo-cabecera, cada uno de los cuales comienza con dos puntos ( :).

En su nivel más básico, un mensaje consta de una cabecera seguida de un cuerpo.

Un encabezado consta de líneas de texto ASCII ; cada una terminada con una secuencia de retorno de carro y salto de línea . El formato tanto para un encabezado de solicitud como para uno de respuesta es:

Línea de salida
Datos estructurados que difieren para la solicitud y la respuesta.
Campos de encabezado
Cero o más líneas de campo de encabezado (al menos 1 para HTTP/1.1); ver más abajo.
Línea vacía
Marca el final del encabezado.

Cuerpo

El cuerpo del mensaje consta de datos en cualquier formato, no limitado a ASCII. El formato debe coincidir con el especificado en el Content-Typecampo de encabezado, si el mensaje lo incluye. El cuerpo es opcional; es decir, puede estar vacío.

Entidad

Antes de HTTP/2, el término «entidad» se utilizaba para referirse al cuerpo más los campos de encabezado que lo describían. En particular, no todos los encabezados se consideraban parte de la entidad. El término «encabezado de entidad» se refería a un encabezado que se consideraba parte de la entidad, y a veces al cuerpo se le llamaba « cuerpo de la entidad» . La documentación moderna utiliza «cuerpo» y «encabezado» sin usar «entidad» .

Campo de encabezado

Un campo de encabezado representa metadatos sobre el mensaje que lo contiene. Algunos ejemplos incluyen cómo se codifica el cuerpo (mediante Content-Encoding ), la verificación de la sesión y la identificación del cliente (como en las cookies del navegador , la dirección IP, el agente de usuario ) o su anonimato (enmascaramiento mediante VPN o proxy, suplantación de agente de usuario), cómo el servidor debe gestionar los datos (como en Do-Not-Track o Control Global de Privacidad ) y la antigüedad (el tiempo que ha permanecido en una caché compartida ) del documento que se está descargando. Generalmente, la información de un campo de encabezado la utiliza el software y no se muestra al usuario .

Una línea de campo de encabezado se formatea como un par nombre-valor con un separador de dos puntos. No se permiten espacios en blanco alrededor del nombre, pero se ignoran los espacios en blanco iniciales y finales para la parte del valor. A diferencia de un nombre de método que debe coincidir exactamente (distingue mayúsculas y minúsculas), [ 28 ] un nombre de campo de encabezado coincide ignorando mayúsculas y minúsculas, aunque a menudo se muestra con cada palabra en mayúscula. [ 29 ] Por ejemplo, los siguientes son campos de encabezado para Hosty Accept-Language.

Servidor: www.example.com Idioma aceptado: en

Los estándares no limitan el tamaño de un campo de encabezado ni el número de campos en un mensaje. Sin embargo, la mayoría de los servidores, clientes y software proxy imponen límites por razones prácticas y de seguridad. Por ejemplo, el servidor Apache 2.3 limita por defecto el tamaño de cada campo a 8190 bytes, y puede haber como máximo 100 campos de encabezado en una sola solicitud. [ 30 ]

Aunque está desaconsejado por RFC 7230, [ 31 ] en el pasado, las líneas largas podían dividirse en varias líneas con una línea de continuación que comenzaba con un espacio o un carácter de tabulación .

Pedido

Un cliente envía una solicitud a un servidor. La línea de inicio incluye el nombre del método, la URI de la solicitud y la versión del protocolo, con un solo espacio entre cada campo. [ 32 ] La siguiente línea de inicio de solicitud especifica el método GET, la URI /customer/123y la versión del protocolo HTTP/1.1:

GET /customer/123 HTTP/1.1

Los campos de encabezado de la solicitud permiten al cliente pasar información adicional más allá de la línea de solicitud, actuando como modificadores de la solicitud (de forma similar a los parámetros de un procedimiento). Proporcionan información sobre el cliente, sobre el recurso de destino o sobre el manejo esperado de la solicitud. En el protocolo HTTP/1.1, todos los campos de encabezado, excepto , Hostson 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 anteriores a la especificación HTTP/1.0 en RFC 1945. [ 33 ] 

Recurso

El protocolo estructura las transacciones operando sobre recursos. El significado de un recurso, ya sean datos preexistentes o generados dinámicamente, depende de la implementación del servidor. Generalmente, el recurso corresponde a un archivo o al resultado de un programa ejecutable en el servidor.

Método

Una solicitud identifica un método (a veces llamado informalmente verbo ) para clasificar la acción deseada que se realizará en un recurso. La especificación HTTP/1.0 [ 3 ] : §8 definió los métodos GET, HEAD y POST, además de enumerar los métodos PUT, DELETE, LINK y UNLINK en métodos adicionales. Sin embargo, la especificación HTTP/1.1 [ 34 ] : §9 agregó cinco nuevos métodos: 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 en la cantidad de métodos que se pueden definir, lo que permite especificar métodos futuros sin romper la infraestructura existente. Por ejemplo, WebDAV definió siete nuevos métodos y RFC 5789 especificó el método PATCH . Se requiere que un servidor web de propósito general implemente al menos GET y HEAD, y todos los demás métodos se consideran opcionales según la especificación. [ 18 ] : §9.1 

Los nombres de los métodos distinguen entre mayúsculas y minúsculas. [ 4 ] : §3 [ 18 ] : §9.1 Esto contrasta con los nombres de los campos de encabezado HTTP, que no distinguen entre mayúsculas y minúsculas. [ 18 ] : §6.3

CONSEGUIR
La solicitud es para una representación de un recurso. El servidor solo debe recuperar datos ; no modificar el estado. [ 1 ] Para recuperar sin realizar cambios, se prefiere GET a POST, ya que se puede acceder a través de una URL . Esto permite guardar marcadores 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, indicando: « El diseño de aplicaciones web debe basarse en los principios anteriores, pero también en las limitaciones pertinentes». [ 35 ]

CABEZA
La solicitud es similar a una GET, excepto que la respuesta no debe incluir los datos de representación en el cuerpo. Esto es útil para recuperar los metadatos de representación en el encabezado de la respuesta, sin tener que transferir la representación completa. Entre sus usos se incluyen comprobar si una página está disponible mediante el código de estado y obtener el tamaño de un archivo mediante un campo de encabezado Content-Length.

CORREO
La solicitud consiste en procesar un recurso de alguna manera. 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 . [ 18 ] : §9.3.3

PONER
La solicitud consiste en crear o actualizar un recurso con el estado especificado en la solicitud. Una diferencia con respecto a POST es que el cliente especifica la ubicación de destino en el servidor. [ 18 ] : §9.3.4

BORRAR
La solicitud consiste en eliminar un recurso.

CONECTAR
Solicita que el intermediario establezca un túnel TCP/IP al servidor de origen identificado por el destino de la solicitud. Se utiliza a menudo para proteger las conexiones a través de uno o más proxies HTTP con TLS . [ 18 ] : §9.3.6 [ 36 ] Véase el método HTTP CONNECT .

OPCIONES
Esta solicitud busca un informe sobre los métodos HTTP compatibles con un recurso. Esto permite comprobar la funcionalidad de un servidor web solicitando '*' en lugar de un recurso específico.

RASTRO
Solicita al servidor que responda con la solicitud recibida en el cuerpo de la respuesta. De esta forma, el cliente puede ver qué cambios o adiciones han realizado los intermediarios (si las hay). Útil para la depuración.

PARCHE
La solicitud consiste en modificar un recurso según su estado parcial en la solicitud. En comparación con PUT, esto puede ahorrar ancho de banda al enviar solo una parte de la representación de un recurso en lugar de la totalidad. [ 37 ]

CONSULTA
Solicita al servidor que procese el contenido adjunto de forma segura e idempotente y que luego responda con el resultado. Esto es similar a las solicitudes POST, pero las solicitudes QUERY se pueden repetir o reiniciar automáticamente sin preocuparse por los cambios de estado parciales. [ 38 ]

Método seguro

Un método de solicitud es seguro si una solicitud realizada con ese método no tiene ningún efecto previsto en el servidor. Los métodos GET, HEAD, OPTIONS y TRACE se definen como seguros. En otras palabras, los métodos seguros están diseñados para ser de solo lectura . Aun así, los métodos seguros pueden tener efectos secundarios que el cliente no percibe, como añadir información de la solicitud a un archivo de registro o realizar cargos a una cuenta publicitaria .

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 estos métodos ; algunos que no las cumplen tienden a realizar solicitudes sin tener en cuenta el contexto ni las consecuencias.

A pesar de la seguridad prescrita para 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 causen 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 podría 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 usando GET, simplemente eliminaría el artículo. [ 39 ] 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 se dio durante la efímera versión beta de Google Web Accelerator , que precargaba URL arbitrarias en la página que el usuario estaba viendo, 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 lanzamiento inicial, tras las numerosas críticas recibidas. [ 40 ]

Método idempotente

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, así como los métodos seguros, se definen como idempotentes. Los métodos seguros son trivialmente idempotentes, ya que están diseñados para no tener ningún efecto en el servidor; los métodos PUT y DELETE, por su parte, son idempotentes, puesto que las solicitudes idénticas sucesivas se ignorarán. 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 pida cambiar la dirección de correo electrónico de un usuario a la misma dirección que ya está registrada (por ejemplo, solicitudes duplicadas después de una solicitud exitosa) no tendrá ningún efecto. Del mismo modo, una solicitud para ELIMINAR a un usuario determinado no tendrá ningún efecto si ese usuario ya ha sido eliminado.

En cambio, los métodos POST, CONNECT y PATCH no son necesariamente idempotentes, por lo que enviar una solicitud POST idéntica varias veces puede modificar el estado del servidor o tener otros efectos, como el envío de múltiples correos electrónicos . En algunos casos, este es el efecto deseado, pero en otros puede ocurrir accidentalmente. Un usuario podría, por ejemplo, enviar inadvertidamente varias solicitudes POST al volver a hacer clic en un botón si no recibe una confirmación clara de que el primer clic se está procesando. Si bien los navegadores web pueden mostrar cuadros de diálogo de alerta para advertir a los usuarios en algunos casos donde recargar una página puede volver a enviar una solicitud POST, generalmente es responsabilidad de la aplicación web gestionar los casos en los que una solicitud POST no debe enviarse más de una vez.

Cabe destacar que el protocolo o el servidor web no imponen la idempotencia de un método. Es perfectamente posible desarrollar una aplicación web en la que (por ejemplo) una inserción en la base de datos u otra acción no idempotente se active mediante una solicitud GET u otra solicitud de este tipo. Sin embargo, hacerlo en contra de las recomendaciones puede tener consecuencias indeseables si el agente de usuario asume que repetir la misma solicitud es seguro cuando no lo es.

Método almacenable en caché

Un método de solicitud es almacenable en caché si las respuestas a las solicitudes realizadas con ese método pueden guardarse para su posterior reutilización. Los métodos GET, HEAD y POST están definidos como almacenables en caché.

Por el contrario, los métodos PUT, DELETE, CONNECT, OPTIONS, TRACE y PATCH no son almacenables en caché.

Respuesta

El servidor envía una respuesta al cliente. La línea de inicio de una respuesta consta de la versión del protocolo, un código de estado y, opcionalmente, una frase de motivo con campos separados por un solo carácter de espacio. [ 4 ] : §2.1 La siguiente línea de inicio de respuesta especifica la versión del protocolo HTTP/1.1, el código de estado 400y la frase de motivo Bad Request.

HTTP/1.1 400 Solicitud incorrecta

Los campos de encabezado de respuesta permiten al servidor transmitir 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 precisarse aún más mediante la semántica del método de solicitud o el código de estado de la respuesta.

Código de estado

El código de estado es un valor entero decimal de tres dígitos que representa la respuesta del servidor a la solicitud del cliente. Generalmente, el cliente procesa la respuesta principalmente en función del código de estado y, en segundo lugar, de los campos del encabezado de respuesta. Es posible que el cliente no comprenda todos los códigos de estado que informa el servidor, pero debe comprender la clase indicada por el primer dígito y tratar un código no reconocido como equivalente al código x00 de esa clase. Las clases son las siguientes:

1XX informativo
Se recibió la solicitud, el proceso continúa.
2XX exitoso
La solicitud fue recibida, comprendida y aceptada satisfactoriamente.
Redirección 3XX
Es necesario tomar medidas adicionales para completar la solicitud.
Error del cliente 4XX
La solicitud no puede ser atendida debido a un problema que el cliente podría controlar.
Error del servidor 5XX
El servidor no pudo procesar una solicitud aparentemente válida.

Frase de razón

Las frases de motivo estándar son solo recomendaciones. Un servidor web puede usar un equivalente localizado. Si un código de estado indica un problema, el agente de usuario podría mostrar la frase de motivo al usuario para brindarle 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 podría no ser recomendable, 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 .

Ejemplo

A continuación se muestra una transacción de solicitud-respuesta HTTP/1.1 para un servidor en www.example.com , puerto 80. HTTP/1.0 usaría los mismos mensajes, excepto por la ausencia de algunos encabezados. HTTP/2 y HTTP/3 usarían el mismo mecanismo de solicitud-respuesta, pero con diferentes representaciones para los encabezados HTTP.

La siguiente es una solicitud sin cuerpo. Consta de una línea de inicio, seis campos de encabezado y una línea en blanco , cada uno finalizado con un retorno de carro y un salto de línea . El Hostcampo de encabezado distingue entre varios nombres DNS que comparten una misma dirección IP , lo que permite el alojamiento virtual basado en nombres . Si bien era opcional en HTTP/1.0, es obligatorio en HTTP/1.1.

GET / HTTP / 1.1 Host : www.example.com User-Agent : Mozilla/5.0 Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language : en-GB,en;q=0.5 Accept-Encoding : gzip, deflate, br Connection : keep-alive

Aunque no se aprecia claramente en la representación anterior (debido a las limitaciones de esta wiki), la línea en blanco al final da como resultado dos secuencias de terminación de línea. Representada como una secuencia de caracteres, una versión abreviada de lo anterior muestra esto con mayor claridad, <CRLF>representando una secuencia de terminación de línea: GET / HTTP/1.1<CRLF>Host: www.example.com<CRLF><CRLF>.

En la siguiente respuesta, 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. El Content-Typecampo de encabezado especifica el tipo de medio de Internet de los datos transmitidos por el mensaje HTTP e Content-Lengthindica su longitud en bytes. El servidor web HTTP/1.1 publica su capacidad para responder a solicitudes de un rango de bytes del recurso incluyendo Accept-Ranges: bytes. Esto es útil si el cliente necesita tener solo ciertas porciones [ 41 ] de un recurso enviado por el servidor, lo que se denomina servicio de bytes . Cuando Connection: closese envía , significa que el servidor web cerrará la conexión TCP inmediatamente después de finalizar la transferencia de esta respuesta. [ 4 ] : ​​§9.1

La mayoría de los campos de encabezado son opcionales, pero algunos son obligatorios. Si Content-Lengthfalta un encabezado en una respuesta con cuerpo, esto se considera un error en HTTP/1.0, pero puede que no lo sea en HTTP/1.1 si el encabezado Transfer-Encoding: chunkedestá presente. La codificación de transferencia por fragmentos 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-Lengthcuando se desconocía la longitud del cuerpo al inicio de la respuesta, por lo que la transferencia de datos al cliente continuaba hasta que el servidor cerraba el socket.

Content-Encoding: gzipInforma al cliente de que el cuerpo del archivo está comprimido según el algoritmo gzip .

HTTP / 1.1 200 OK Fecha : lun, 23 may 2005 22:38:34 GMT Tipo de contenido : texto/html; charset=UTF-8 Longitud del contenido : 155 Última modificación : mié, 08 ene 2003 23:11:55 GMT Servidor : Apache/1.3.3.7 (Unix) (Red-Hat/Linux) ETag : "3f80f-1b6-3e1cb03b" Rangos aceptados : bytes Conexión : cerrar<html> <head> <title> Una página de ejemplo </title> </head> <body> <p> Hola mundo , este es un documento HTML muy simple . </p> </body> </html>​​​​​​​

Protocolos similares

Protocolo Gopher
Un protocolo de entrega de contenido que fue reemplazado por HTTP a principios de la década de 1990.
Protocolo SPDY
Una alternativa a HTTP desarrollada en Google , reemplazada por HTTP/2 .
Protocolo Géminis
Un protocolo inspirado en Gopher que exige características relacionadas con la privacidad.

Historia

Tim Berners-Lee

A Tim Berners-Lee y su equipo en el CERN se les atribuye la invención de HTTP, junto con HTML y la tecnología asociada para un servidor web y una interfaz de usuario cliente llamada navegador web . Berners-Lee diseñó 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 la World Wide Web . El desarrollo de HTTP se inició en 1989 y se resumió en un documento simple que describía el comportamiento de un cliente y un servidor usando la primera versión de HTTP, llamada 0.9. [ 42 ] Esa versión se desarrolló posteriormente, convirtiéndose finalmente en la versión pública 1.0. [ 43 ] El desarrollo de los primeros documentos de Solicitud de Comentarios (RFC) de 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 pasó más tarde al IETF.

El primer servidor web se puso en marcha en 1990. [ 44 ] [ 45 ] El protocolo utilizado tenía un único método, el GET, que solicitaba una página a un servidor. [ 46 ] La respuesta del servidor siempre era una página HTML. [ 42 ]

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 la carga de información. [ 42 ]

HTTP/1.0-borrador

Desde 1992, se redactó un nuevo documento para especificar la evolución del protocolo básico hacia su siguiente versión completa. Este documento 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. [ 43 ]

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 documentarse completamente como documentos RFC oficiales, a principios de 1995, se constituyó el Grupo de Trabajo HTTP (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, vinculada a un protocolo de seguridad que se volvió más eficiente al agregar métodos y campos de encabezado adicionales . [ 47 ] [ 48 ]

El Grupo de Trabajo 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 se extendió mucho más de un año. [ 49 ]

El Grupo de Trabajo de HTTP también planeó especificar una versión 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 [ 3 ] como una revisión final de HTTP/1.0 de lo que se había utilizado en los 4 años anteriores como un borrador preestándar de HTTP/1.0 que ya era utilizado por muchos navegadores web y servidores web. 

A principios de 1996, los desarrolladores comenzaron incluso a incluir extensiones no oficiales del protocolo HTTP/1.0 (es decir, conexiones keep-alive, etc.) en sus productos utilizando borradores de las próximas especificaciones HTTP/1.1. [ 20 ]

HTTP/1.1

Desde principios de 1996, los principales navegadores web y desarrolladores de servidores web también comenzaron a implementar nuevas características especificadas en los borradores de las especificaciones preestá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 para junio de 1996, el 65 % de todos los navegadores que accedían a sus servidores cumplían con el estándar preestándar HTTP/1.1. [ 50 ]

En enero de 1997, el RFC 2068 [ 51 ] se publicó oficialmente como especificaciones HTTP/1.1. 

En junio de 1999, se publicó el RFC 2616 [ 34 ] para incluir todas las mejoras y actualizaciones basadas en las especificaciones HTTP/1.1 anteriores (obsoletas). 

Grupo de trabajo HTTP-NG del W3C

Retomando el antiguo plan de 1995 del anterior Grupo de Trabajo HTTP, en 1997 se formó un Grupo de Trabajo HTTP-NG para desarrollar un nuevo protocolo HTTP denominado HTTP-NG (HTTP de Nueva Generación). 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 cesó su actividad y transfirió los problemas técnicos al IETF. [ 52 ]

El grupo de trabajo HTTP de la IETF se reinició.

En 2007, el Grupo de Trabajo HTTP de la IETF (HTTP WG bis o HTTPbis) se reactivó primero para revisar y aclarar las especificaciones HTTP/1.1 anteriores y, segundo, para escribir y perfeccionar las futuras especificaciones HTTP/2 (denominadas httpbis). [ 53 ] [ 54 ]

SPDY

En 2009, Google anunció SPDY , un protocolo binario que desarrollaron para acelerar el tráfico web entre navegadores y servidores. En muchas pruebas, el uso de SPDY resultó ser más rápido que el de HTTP/1.1. SPDY se integró en Chromium de Google y posteriormente en otros navegadores web importantes. [ 55 ] Algunas de las ideas sobre la multiplexación de flujos HTTP a través de una única conexión TCP se tomaron de diversas fuentes, incluido el trabajo del Grupo de Trabajo HTTP-NG del W3C.

HTTP/2

En 2012, el Grupo de Trabajo HTTP (HTTPbis) anunció la necesidad de un nuevo protocolo; inicialmente consideró aspectos de SPDY [ 56 ] [ 57 ] y finalmente decidió derivar el nuevo protocolo de SPDY. [ 58 ] En mayo de 2015, HTTP/2 se publicó como RFC 7540 [ 59 ] . El protocolo fue rápidamente adoptado por 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 que dejó obsoleta la RFC 2616 [ 34 ] : 

  • RFC 7230 – " Protocolo de transferencia de hipertexto (HTTP/1.1): Sintaxis y enrutamiento de mensajes " , [ 60 ] Obsoleto. 
  • RFC 7231 – " Protocolo de transferencia de hipertexto (HTTP/1.1): semántica y contenido " , [ 61 ] Obsoleto. 
  • RFC 7232 – " Protocolo de transferencia de hipertexto (HTTP/1.1): solicitudes condicionales, " [ 62 ] Obsoleto. 
  • RFC 7233 – " Protocolo de transferencia de hipertexto (HTTP/1.1): solicitudes de rango, " [ 63 ] Obsoleto. 
  • RFC 7234 – " Protocolo de transferencia de hipertexto (HTTP/1.1): Almacenamiento en caché, " [ 64 ] Obsoleto. 
  • RFC 7235 – " Protocolo de transferencia de hipertexto (HTTP/1.1): Autenticación, " [ 65 ] Obsoleto. 

Obsolescencia de HTTP/0.9

En 2014, HTTP/0.9 quedó obsoleto para los servidores que admiten la versión HTTP/1.1 (y superior): [ 60 ] : §Apéndice A

Dado que HTTP/0.9 no admitía campos de encabezado en una solicitud, no existe un mecanismo para admitir 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 codifica correctamente el destino de la solicitud.

Desde 2016, muchos gerentes de producto y desarrolladores de agentes de usuario (navegadores, etc.) y servidores web han comenzado a planificar la descontinuación gradual y el descarte del soporte para el protocolo HTTP/0.9, principalmente por las siguientes razones: [ 66 ]

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

A fecha de 2022, la compatibilidad con HTTP/0.9 no se ha descontinuado oficialmente por completo y sigue presente en muchos servidores web y navegadores (solo para las respuestas del servidor), aunque normalmente esté deshabilitada. Se desconoce cuánto tiempo llevará eliminar por completo HTTP/0.9.

HTTP/3

En 2020, se publicaron los primeros borradores de HTTP/3 y los principales navegadores web y servidores web comenzaron a adoptarlo. El 6 de junio de 2022, el IETF estandarizó HTTP/3 como RFC 9114 [ 67 ] . 

Actualizaciones y refactorización en 2022

En junio de 2022, se publicaron documentos RFC que dejaban obsoletos muchos de los documentos anteriores e introducían algunos cambios menores y una refactorización de la descripción de la semántica HTTP en un documento aparte.

  • RFC 9110 – " Semántica HTTP " , [ 18 ] Estándar de Internet 97. 
  • RFC 9111 – " Almacenamiento en caché HTTP " , [ 68 ] Estándar de Internet 98. 
  • RFC 9112 – " HTTP/1.1, " [ 4 ] Estándar de Internet 99. 
  • RFC 9113 – " HTTP/2, " [ 6 ] Estándar propuesto. 
  • RFC 9114 – " HTTP/3, " [ 67 ] Estándar propuesto. (Véase también la sección anterior.) 
  • RFC 9204 – " QPACK: Compresión de campos para HTTP/3, " [ 69 ] Estándar propuesto. 
  • RFC 9218 – " Esquema de priorización extensible para HTTP " , [ 70 ] Estándar propuesto. 

Véase también

Notas

  1. ↑ En la práctica, estos flujos se utilizan como múltiples subconexiones TCP/IP para multiplexar solicitudes/respuestas concurrentes, lo que reduce considerablemente el número de conexiones TCP/IP reales en el servidor, de 2 a 8 por cliente a 1, y permite atender a muchos más clientes a la vez.
  2. ↑ Desde finales de 1996, algunos desarrolladores de navegadores y servidores HTTP/1.0 populares (especialmente aquellos que también habían planeado dar soporte a HTTP/1.1) comenzaron a implementar (como una extensión no oficial) una especie de mecanismo keep-alive (mediante el uso de nuevas cabeceras HTTP) para mantener abierta la conexión TCP/IP durante más de un par de solicitud/respuesta y así acelerar el intercambio de múltiples solicitudes/respuestas. [ 20 ]

Referencias

  1. 1 2 3 Fielding, Roy T.; Nottingham, Mark; Reschke, Julian (junio de 2022). Semántica HTTP (Informe). Grupo de Trabajo de Ingeniería de Internet. Archivado del original el 16 de abril de 2026.
  2. ↑ T. Berners-Lee ; R. Fielding ; L. Masinter (enero de 2005). Identificador uniforme de recursos (URI): sintaxis genérica . Grupo de trabajo de redes. doi : 10.17487/RFC3986 . STD 66. RFC 3986 .Estándar de Internet 66. Deja obsoletos los RFC 2732 , 2396 y 1808. Actualizado por los RFC 6874 , 7320 y 8820. Actualiza el RFC 1738 .   
  3. 1 2 3 4 T Berners-Lee ; R. Fielding ; H. Frystyk (mayo de 1996). Protocolo de transferencia de hipertexto -- HTTP/1.0 . Grupo de trabajo de redes. doi : 10.17487/RFC1945 . RFC 1945 .Informativo.
  4. 1 2 3 4 5 6 R. Fielding ; M. Nottingham; J. Reschke, eds. (junio de 2022). HTTP/1.1 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9112 . ISSN 2070-1721 . STD 99. RFC 9112 . Estándar de Internet 99. Obsoleto RFC 7230 . 
  5. ↑ "Documentos HTTP clásicos" . W3.org. 14 de mayo de 1998. Archivado del original el 11 de marzo de 2026. Consultado el 1 de agosto de 2010 .
  6. 1 2 3 M. Thomson; C. Benfield, eds. (junio de 2022). HTTP/2 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9113 . ISSN 2070-1721 . RFC 9113 . Norma propuesta. Sustituye a las RFC 8740 y 7540 . 
  7. ↑ "Estadísticas de uso de HTTP/2 para sitios web" . w3techs.com . Consultado el 21 de enero de 2026 .
  8. ↑ "Estadísticas de uso de HTTP/3 para sitios web, enero de 2026" . w3techs.com . Consultado el 21 de enero de 2026 .
  9. ↑ "¿Puedo usar... Tablas de soporte para HTML5, CSS3, etc." . caniuse.com . Consultado el 5 de enero de 2024 .
  10. ↑ S. Friedl; A. Popov; A. Langley; E. Stephan (julio de 2014). Extensión de negociación del protocolo de capa de aplicación de seguridad de la capa de transporte (TLS) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7301 . ISSN 2070-1721 . RFC 7301 . Estándar propuesto. Actualizado por RFC 8447 . 
  11. ↑ "Estadísticas de uso de HTTP/3 para sitios web" . w3techs.com . Consultado el 18 de enero de 2026 .
  12. ↑ "¿Puedo usar... Tablas de soporte para HTML5, CSS3, etc." . canIuse.com . Consultado el 8 de enero de 2024 .
  13. ↑ 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 .
  14. ↑ "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 .
  15. ↑ "Firefox Nightly admite HTTP 3 – General – Comunidad de Cloudflare" . 19 de noviembre de 2019. Consultado el 23 de enero de 2020 .
  16. ↑ "HTTP/3 es rápido" . Métricas de solicitud . Consultado el 1 de julio de 2022 .
  17. ↑ "Estadísticas de uso del protocolo predeterminado https para sitios web" . w3techs.com . Consultado el 5 de enero de 2024 .
  18. 1 2 3 4 5 6 7 8 9 10 R. Fielding ; M. Nottingham; J. Reschke, eds. (junio de 2022). HTTP Semantics . Internet Engineering Task Force . doi : 10.17487/RFC9110 . ISSN 2070-1721 . STD 97. RFC 9110 . Estándar de Internet 97. Deja obsoletos los RFC 2818 , 7230 , 7231 , 7232 , 7233 , 7235 , 7538 , 7615 y 7694. Actualiza el RFC 3864 .  
  19. 1 2 "Conexiones, clientes y servidores" . RFC 9110, Semántica HTTP . IETF . sec. 3.3. doi : 10.17487/RFC9110 . RFC 9110 . 
  20. 1 2 David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: La guía definitiva. (fragmento del capítulo: "Conexiones persistentes") . O'Reilly Media, Inc. ISBN 978-1-56592-509-0. Consultado el 18 de octubre de 2021 .
  21. ↑ Lee, Wei-Bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (2019-01-25). "Protección segura y eficiente para cookies HTTP con autoverificación" . International Journal of Communication Systems . 32 (2) e3857. doi : 10.1002/dac.3857 . S2CID 59524143 . 
  22. ↑ Canavan, John (2001). Fundamentos de seguridad en redes . Norwood, MA: Artech House. págs. 82–83 . ISBN  978-1-58053-176-4.
  23. ↑ Zalewski, Michal. "Manual de seguridad del navegador" . Consultado el 30 de abril de 2015 .{{cite web}}: CS1 mantenimiento: estado de la URL ( enlace )
  24. ↑ "Chromium Issue 4527: implement RFC 2817: Upgradeing to TLS Within HTTP/1.1" . Consultado el 30 de abril de 2015 .
  25. ↑ "Mozilla Bug 276813 – [ RFE ] Compatibilidad con RFC 2817 / Actualización de TLS para HTTP 1.1" . Consultado el 30 de abril de 2015 .
  26. ↑ HTTP/2 . IETF . Junio ​​2022. doi : 10.17487/RFC9113 . RFC 9113 .
  27. ↑ Peon, R.; Ruellan, H. (mayo de 2015). HPACK: Compresión de encabezados para HTTP/2 . IETF . doi : 10.17487/RFC7541 . RFC 7541 .
  28. ↑ "Métodos: Descripción general" . Semántica HTTP . IETF . Junio ​​de 2022. Sec. 9.1. doi : 10.17487/RFC9110 . RFC 9110 . 
  29. ↑ "Nombres de campo" . Semántica HTTP . IETF . Junio ​​de 2022. Sec. 5.1. doi : 10.17487/RFC9110 . RFC 9110 . 
  30. ↑ "core - Apache HTTP Server" . Httpd.apache.org. Archivado del original el 9 de mayo de 2012. Consultado el 13 de marzo de 2012 .
  31. ↑ "Análisis de campos" . Protocolo de transferencia de hipertexto (HTTP/1.1): Sintaxis y enrutamiento de mensajes . IETF . Junio ​​de 2014. sec. 3.2.4. doi : 10.17487/RFC7230 . RFC 7230 . 
  32. ↑ "Formato de mensaje" . RFC 9112: HTTP/1.1 . IETF . sec. 2.1. doi : 10.17487/RFC9112 . RFC 9112 . 
  33. ↑ "Semana de Apache. HTTP/1.1" . Archivado del original el 2 de junio de 2021. Consultado el 3 de mayo de 2021 .090502 apacheweek.com
  34. 1 2 3 R. Fielding ; J. Gettys; J. Mogul; H. Frystyk ; L. Masinter ; P. Leach; T. Berners-Lee (agosto de 1999). Protocolo de transferencia de hipertexto -- HTTP/1.1 . Grupo de trabajo de redes. doi : 10.17487/RFC2616 . RFC 2616 .Obsoleto. Obsoleto según RFC 7230 , 7231 , 7232 , 7233 , 7234 y 7235. Obsoleto según RFC 2068. Actualizado por RFC 2817 , 5785 , 6266 y 6585 .   
  35. ↑ Jacobs, Ian (2004). "URIs, direccionabilidad y el uso de HTTP GET y POST" . Hallazgo del Grupo de Arquitectura Técnica . W3C . Recuperado el 26 de septiembre de 2010 .
  36. ↑ "Nota de vulnerabilidad VU#150227: Las configuraciones predeterminadas del proxy HTTP permiten conexiones TCP arbitrarias" . US-CERT . 17 de mayo de 2002. Consultado el 10 de mayo de 2007 .
  37. ↑ L. Dusseault; J. Snell (marzo de 2010). Método PATCH para HTTP . Grupo de Trabajo de Investigación de Internet . doi : 10.17487/RFC5789 . ISSN 2070-1721 . RFC 5789 . Norma propuesta.
  38. ↑ J. Reschke; JM Snell; M. Bishop (junio de 2026). El método HTTP QUERY . Internet Research Task Force . doi : 10.17487/RFC10008 . ISSN 2070-1721 . RFC 10008 . Norma propuesta.
  39. ↑ Ediger, Brad (21 de diciembre de 2007). Advanced Rails: Creación de aplicaciones web de alto rendimiento en tiempo récord . O'Reilly Media, Inc. pág. 188. ISBN  978-0-596-51972-8Un error común es usar GET para una acción que actualiza un recurso. [...] Este problema salió a la luz pública en Rails en 2005, con el lanzamiento de Google Web Accelerator .
  40. ↑ Cantrell, Christian (1 de junio de 2005). "¿Qué hemos aprendido del acelerador web de Google?" . Blogs de Adobe . Adobe. Archivado del original el 19 de agosto de 2017. Consultado el 19 de noviembre de 2018 .
  41. ↑ Luotonen, Ari; Franks, John (22 de febrero de 1996). Extensión de recuperación de rango de bytes a HTTP . IETF. ID draft-ietf-http-range-retrieval-00.
  42. 1 2 3 4 Tim Berner-Lee (1991-01-01). "El HTTP original tal como se definió en 1991" . www.w3.org . Consorcio World Wide Web . Recuperado el 24 de julio de 2010 .
  43. 1 2 Tim Berner-Lee (1992). "HTTP básico según se definió en 1992" . www.w3.org . Consorcio World Wide Web . Recuperado el 19 de octubre de 2021 .
  44. ↑ "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 .
  45. ↑ Berners-Lee, Tim (1990-10-02). "daemon.c - Servidor basado en TCP/IP para hipertexto" . www.w3.org . Recuperado el 2021-08-11 .
  46. ↑ Berners-Lee, Tim. "Protocolo de transferencia de hipertexto" . Consorcio World Wide Web . Consultado el 31 de agosto de 2010 .
  47. ↑ Raggett, Dave. "Biografía de Dave Raggett" . Consorcio World Wide Web . Consultado el 11 de junio de 2010 .
  48. ↑ Raggett, Dave; Berners-Lee, Tim. "Grupo de trabajo del protocolo de transferencia de hipertexto" . Consorcio World Wide Web . Consultado el 29 de septiembre de 2010 .
  49. ↑ Raggett, Dave. "Planes del Grupo de Trabajo HTTP" . Consorcio World Wide Web . Consultado el 29 de septiembre de 2010 .
  50. ↑ "Navegadores compatibles con HTTP 1.1" . webcom.com . Archivado del original el 4 de febrero de 1998. Consultado el 29 de mayo de 2009 .
  51. ↑ R. Fielding ; J. Gettys; J. Mogul; H. Frystyk ; T. Berners-Lee (enero de 1997). Protocolo de transferencia de hipertexto -- HTTP/1.1 . Grupo de trabajo de redes. doi : 10.17487/RFC2068 . RFC 2068 .Obsoleto. Obsoleto según RFC 2616 . 
  52. ↑ "Grupo de Trabajo HTTP-NG" . www.w3.org . Consorcio World Wide Web. 1997. Consultado el 19 de octubre de 2021 .
  53. ↑ Administrador web (2007). "Grupo de trabajo HTTP" . httpwg.org . IETF . Consultado el 19 de octubre de 2021 .
  54. ↑ Administrador web (2007). "Grupo de trabajo HTTP: estatuto httpbis" . datatracker.ietf.org . IETF . Consultado el 19 de octubre de 2021 .
  55. ↑ "SPDY: Un protocolo experimental para una web más rápida" . dev.chromium.org . Google. 1 de noviembre de 2009. Consultado el 19 de octubre de 2021 .
  56. ↑ "Renovación de httpbis" . IETF; HTTP WG. 24 de enero de 2012. Consultado el 19 de octubre de 2021 .
  57. ↑ Secretario del IESG (19 de marzo de 2012). "Acción del Grupo de Trabajo: RECARGO: Protocolo de Transferencia de Hipertexto Bis (httpbis)" . IETF; Grupo de Trabajo HTTP . Consultado el 19 de octubre de 2021 .
  58. ↑ Ilya Grigorik; Surma (3 de septiembre de 2019). "Redes de navegador de alto rendimiento: Introducción a HTTP/2" . developers.google.com . Google Inc. Recuperado el 19 de octubre de 2021 .
  59. ↑M. Belshe; R. Peon (May 2015). M. Thomson (ed.). Hypertext Transfer Protocol Version 2 (HTTP/2). Internet Engineering Task Force. doi:10.17487/RFC7540. ISSN 2070-1721. RFC7540.Proposed Standard. Updated by RFC 8740.
  60. 12R. Fielding; J. Reschke, eds. (June 2014). Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. Internet Engineering Task Force. doi:10.17487/RFC7230. RFC7230.Obsolete. Obsoleted by RFC 9110 and 9112. Updated by RFC 8615. Obsoletes RFC 2145 and 2616. Updates RFC 2817 and 2818.
  61. ↑R. Fielding; J. Reschke, eds. (June 2014). Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Internet Engineering Task Force. doi:10.17487/RFC7231. RFC7231.Obsolete. Obsoleted by RFC 9110. Obsoletes RFC 2616. Updates RFC 2817.
  62. ↑R. Fielding; J. Reschke, eds. (June 2014). Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. Internet Engineering Task Force. doi:10.17487/RFC7232. RFC7232.Obsolete. Obsoleted by RFC 9110. Obsoletes RFC 2616.
  63. ↑R. Fielding; Y. Lafon; J. Reschke, eds. (June 2014). Hypertext Transfer Protocol (HTTP/1.1): Range Requests. Internet Engineering Task Force. doi:10.17487/RFC7233. RFC7233.Obsolete. Obsoleted by RFC 9110. Obsoletes RFC 2616.
  64. ↑R. Fielding; M. Nottingham; J. Reschke (June 2014). Hypertext Transfer Protocol (HTTP/1.1): Caching. Internet Engineering Task Force. doi:10.17487/RFC7234. RFC7234.Obsolete. Obsoleted by RFC 9111. Obsoletes RFC 2616.
  65. ↑ R. Fielding ; J. Reschke, eds. (junio de 2014). Protocolo de transferencia de hipertexto (HTTP/1.1): Autenticación . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7235 . RFC 7235 .Obsoleto. Obsoleto según RFC 9110. Obsoleto según RFC 2617 , 2616 .  
  66. ↑ Matt Menke (30 de junio de 2016). "Intención de descontinuar y eliminar: Soporte para HTTP/0.9" . groups.google.com . Consultado el 15 de octubre de 2021 .
  67. 1 2 M. Bishop, ed. (junio de 2022). HTTP/3 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9114 . ISSN 2070-1721 . RFC 9114 . Norma propuesta.
  68. ↑ R. Fielding ; M. Nottingham; J. Reschke (junio de 2022). Almacenamiento en caché HTTP . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9111 . STD 98. RFC 9111 .Estándar de Internet 98. Obsoleto RFC 7234 . 
  69. ↑ C. Krasic; M. Bishop (junio de 2022). A. Frindell (ed.). QPACK: Compresión de campos para HTTP/3 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9204 . ISSN 2070-1721 . RFC 9204 . Norma propuesta.
  70. ↑奥 一穂 (K. Oku); L. Pardue (junio de 2022). Esquema de priorización extensible para HTTP . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9218 . ISSN 2070-1721 . RFC 9218 . Norma propuesta.
  • Sitio web oficialEdita esto en Wikidata
  • 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.
  • "Problemas de diseño para HTTP" . W3.org . Consultado el 1 de agosto de 2010 .Problemas de diseño detectados por Berners-Lee al diseñar el protocolo.
Lecturas relacionadas
6 articulos
Capa de aplicaciónCapa de aplicaciónUna capa de aplicación es una capa de abstracción que especifica los protocolos de comunicación compartidos y los métodos de interfaz utilizados po...Conjunto de protocolos de InternetConjunto de protocolos de InternetEl conjunto de protocolos de Internet , comúnmente conocido como TCP/IP , es un marco para organizar el conjunto de protocolos de comunicación util...HipermediaHipermediaHipermedia , una extensión de hipertexto , es un medio no lineal de información que incluye gráficos, audio, video, texto simple e hipervínculos . ...World Wide WebWorld Wide WebUna página web de Wikipedia mostrada en Google Chrome La World Wide Web ( WWW o simplemente la Web ) es un sistema de información que permite compa...HipertextoHipertextoEl hipertexto es un texto que se muestra en la pantalla de una computadora u otros dispositivos electrónicos con referencias ( hipervínculos ) a ot...HiperenlaceHiperenlaceEn informática , un hipervínculo , o simplemente un enlace , es una referencia digital a datos que el usuario puede seguir o hacia los que puede se...