HTTP

El Protocolo de transferencia de hipertexto (HTTP) 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. 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 se resume en un documento simple que describe el comportamiento de un cliente y un servidor utilizando la primera versión del protocolo HTTP que se denominó 0.9.

Esa primera versión del protocolo HTTP pronto se convirtió en una versión más elaborada que fue el primer borrador de una futura versión 1.0.

El desarrollo de las primeras solicitudes de comentarios (RFC) HTTP comenzó unos años más tarde y fue un esfuerzo coordinado del Grupo de trabajo de ingeniería de Internet (IETF) y el Consorcio World Wide Web (W3C), y el trabajo se trasladó más tarde al IETF.

HTTP/1 se finalizó y documentó por completo (como versión 1.0) en 1996. Evolucionó (como versión 1.1) en 1997 y luego sus especificaciones se actualizaron en 1999 y en 2014.

Su variante segura llamada HTTPS es utilizada por más del 79% de los sitios web.

HTTP/2 es una expresión más eficiente de la semántica de HTTP "en el cable" y se publicó en 2015; utilizado por más del 46% de los sitios web, ahora compatible con casi todos los navegadores web (96% de los usuarios) y los principales servidores web sobre Transport Layer Security (TLS) usando una extensión de negociación de protocolo de capa de aplicación (ALPN) donde TLS 1.2 o más reciente es requerido.

HTTP/3 es el sucesor propuesto de HTTP/2, está cerca de ser estandarizado; ya utilizado por el 25% de los sitios web; ahora es compatible con muchos navegadores web (73% de los usuarios). HTTP/3 utiliza 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. La compatibilidad con HTTP/3 se agregó primero a Cloudflare y Google Chrome, y también está habilitada en Firefox.

Resumen técnico

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 incluir el contenido solicitado en el cuerpo del mensaje.

Un navegador web es un ejemplo de un agente de usuario (UA). 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 habiliten las comunicaciones entre clientes y servidores. Los sitios web de alto tráfico a menudo se benefician 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 de los clientes sin una dirección enrutable globalmente, mediante la retransmisión de 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 por salto, mientras que otros encabezados HTTP se administran de extremo a extremo. final (administrado 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 supone un protocolo de capa de transporte subyacente y confiable, por lo que el Protocolo de control de transmisión (TCP) se usa comúnmente. Sin embargo, HTTP se puede adaptar para usar protocolos no confiables, como el Protocolo de datagramas de usuario (UDP), por ejemplo, en HTTPU y el Protocolo simple de detección 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. Tal como se define en RFC 3986, los URI se codifican como hipervínculos en documentos HTML, para formar documentos de hipertexto interrelacionados.

En HTTP/1.0, se realiza una conexión separada al mismo servidor para cada solicitud de recursos.

En cambio, en HTTP/1.1 se puede reutilizar una conexión TCP para realizar múltiples solicitudes de recursos (es decir, de páginas HTML, marcos, imágenes, scripts, hojas de estilo, etc.).

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.

HTTP/2 es una revisión del anterior HTTP/1.1 para mantener el mismo modelo cliente-servidor y los mismos métodos de protocolo pero con estas diferencias en el orden:

• usar 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 cifrada) por dominio de servidor al que se accede en lugar de 2 a 8 conexiones TCP/IP;
• utilizar uno o más flujos bidireccionales por conexión TCP/IP en los que las solicitudes y respuestas HTTP se desglosan y se transmiten en pequeños paquetes para resolver casi por completo el problema del HOLB (bloqueo de cabeza de línea).
• para agregar una capacidad de inserción para permitir que la aplicación del servidor envíe datos a los clientes siempre que haya nuevos datos disponibles (sin obligar a los clientes a solicitar periódicamente nuevos datos al servidor mediante el uso de métodos de sondeo).

Por lo tanto, las comunicaciones HTTP/2 experimentan una latencia mucho menor y, en la mayoría de los casos, incluso más velocidad que las comunicaciones HTTP/1.1.

HTTP/3 es una revisión del HTTP/2 anterior para usar protocolos de transporte QUIC + UDP en lugar de conexiones TCP/IP, también para mejorar ligeramente la velocidad promedio de las comunicaciones y evitar el problema ocasional (muy raro) de la conexión TCP/IP. congestión que puede bloquear o ralentizar temporalmente el flujo de datos de todos sus flujos (otra forma de " bloqueo de cabecera de línea ").

Historia

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 la década de 1930 del sistema "memex" de recuperación y gestión de información basado en microfilmes descrito en su ensayo de 1945 "As We May Think". A Tim Berners-Lee y su equipo en el 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 propuso por primera vez el proyecto "WorldWideWeb" en 1989, ahora conocido como World Wide Web.

El primer servidor web se puso en marcha en 1990. El protocolo utilizado tenía un solo método, a saber, GET, que solicitaría una página de un servidor. La respuesta del servidor siempre fue una página HTML.

Resumen de versiones de hitos de HTTP

Versión	año introducido	Estado actual
HTTP/0.9	1991	Obsoleto
HTTP/1.0	1996	Obsoleto
HTTP/1.1	1997	Estándar
HTTP/2	2015	Estándar
HTTP/3	2020	Reclutar

HTTP/0.9En 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. HTTP/0.9 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.HTTP/1.0-borradorDesde 1992 se redactó 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 en HTTP/1.0.Grupo de trabajo HTTP del W3CDespués de haber decidido que se requerían nuevas características del protocolo HTTP y que debían estar completamente documentadas como 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 con un protocolo de seguridad que se volvió más eficiente al agregar métodos adicionales y campos de encabezado.El HTTP WG 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.El HTTP WG planeó también especificar una versión futura lejana de HTTP llamada HTTP-NG (HTTP Next Generation) que habría resuelto todos los problemas restantes de versiones anteriores, relacionados con el rendimiento, respuestas de baja latencia, etc. unos años más tarde y nunca se completó.HTTP/1.0En mayo de 1996, se publicó RFC 1945 como una revisión final de HTTP/1.0 de lo que se había utilizado en los 4 años anteriores como borrador de HTTP/1.0 preestándar que ya utilizaban 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 permanentes, etc.) en sus productos utilizando borradores de las próximas especificaciones HTTP/1.1.HTTP/1.1Desde principios de 1996, los principales navegadores web y desarrolladores de servidores web también comenzaron a implementar nuevas funciones especificadas por los borradores de especificaciones HTTP/1.1 preestándar. La adopción por parte del usuario final de las nuevas versiones de navegadores y servidores fue rápida. En marzo de 1996, una empresa de hospedaje web informó que más del 40% de los navegadores en uso en Internet usaban el nuevo encabezado HTTP/1.1 "Host" para habilitar el hospedaje virtual. Esa misma empresa de alojamiento web informó que en junio de 1996, el 65% de todos los navegadores que accedían a sus servidores cumplían con el estándar HTTP/1.1.En enero de 1997, RFC 2068 se publicó oficialmente como especificaciones HTTP/1.1.En junio de 1999, se publicó RFC 2616 para incluir todas las mejoras y actualizaciones basadas en especificaciones HTTP/1.1 anteriores (obsoletas).Grupo de trabajo HTTP-NG del W3CReanudando el antiguo plan de 1995 del Grupo de Trabajo HTTP anterior, en 1997 se formó un Grupo de Trabajo HTTP-NG para desarrollar un nuevo protocolo HTTP llamado HTTP-NG (HTTP Nueva Generación). Se produjeron algunas propuestas/borradores para el nuevo protocolo para utilizar la multiplexación de transacciones HTTP dentro de una única conexión TCP/IP, pero en 1999, el grupo detuvo su actividad pasando los problemas técnicos a IETF.Se reinició el grupo de trabajo HTTP de IETFEn 2007, el Grupo de trabajo HTTP de IETF (HTTP WG bis o HTTPbis) se reinició en primer lugar para revisar y aclarar las especificaciones HTTP/1.1 anteriores y, en segundo lugar, para redactar y perfeccionar las futuras especificaciones HTTP/2 (denominadas httpbis).Actualización final de HTTP/1.1En junio de 2014, el grupo de trabajo de HTTP publicó una especificación HTTP/1.1 de seis partes actualizada que deja obsoleta la RFC 2616:

• RFC 7230, HTTP/1.1: enrutamiento y sintaxis 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

SPDY: un protocolo HTTP no oficial desarrollado por GoogleEn 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 en gran medida 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 adoptado rápidamente por Chromium y luego por otros navegadores web importantes.Algunas de las ideas sobre la multiplexación de secuencias HTTP en una sola conexión TCP/IP se tomaron de varias fuentes, incluido el trabajo del Grupo de Trabajo HTTP-NG del W3C.HTTP/2En 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 teniendo en cuenta las ideas y el trabajo realizado para SPDY.Después de unos meses sobre qué hacer para desarrollar una nueva versión de HTTP, se decidió derivarla de SPDY.En mayo de 2015, HTTP/2 se publicó como RFC 7540 y fue rápidamente adoptado por todos los navegadores web que ya eran compatibles con SPDY y, más lentamente, por los servidores web.Desactivación de HTTP/0.9En RFC 7230 Apéndice-A, HTTP/0.9 quedó en desuso para servidores compatibles con la versión HTTP/1.1 (y superior):

Dado que HTTP/0.9 no admitía campos de encabezado en una solicitud, no existe ningún 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 debe 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 objetivo de la solicitud.

Desde 2016, muchos gerentes de producto y desarrolladores de agentes de usuario (navegadores, etc.) y servidores web han comenzado a planear dejar de usar y descartar gradualmente el soporte para el protocolo HTTP/0.9, principalmente por las siguientes razones:

• es tan simple que nunca se escribió un documento RFC (solo existe el documento original);
• no tiene encabezados HTTP y carece de muchas otras características que hoy en día se requieren por razones mínimas de seguridad;
• no se ha generalizado desde 1999...2000 (debido a HTTP/1.0 y HTTP/1.1) y es comúnmente utilizado solo por hardware de red muy antiguo, es decir, enrutadores, etc.

HTTP/3En 2020, se publicaron los primeros borradores de HTTP/3 y los principales navegadores web y servidores web comenzaron a adoptarlo.

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. En las implementaciones de HTTP, las conexiones TCP/IP se utilizan utilizando puertos bien 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 la Lista de números de puerto TCP y UDP). En HTTP/2, se utilizan una conexión TCP/IP más varios 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 y respuesta que se intercambian mediante una conexión de transporte de capa de sesión.Un cliente HTTP inicialmente intenta 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 el mensaje de solicitud de un cliente. El cliente envía su solicitud al servidor. Al recibir la solicitud, el servidor devuelve un mensaje de respuesta HTTP (encabezado más cuerpo si es necesario). El cuerpo de este mensaje suele ser 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 cliente.

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.

En HTTP/1.1 se introdujo oficialmente un mecanismo de mantenimiento de conexión para que una conexión pudiera reutilizarse para más de una solicitud/respuesta. Dichas conexiones persistentes reducen perceptiblemente la latencia de las solicitudes porque el cliente no necesita volver a negociar la conexión TCP de tres vías 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.1También se agregó canalización HTTP para reducir aún más el tiempo de retraso cuando se usan 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 los servidores proxy transparentes ubicados en Internet/Intranets entre clientes y servidores, no manejaron correctamente las solicitudes canalizadas (solo atendieron la primera solicitud descartando las demás, cerraron la conexión porque vieron más datos después de la primera solicitud o algunos proxies incluso devolvieron respuestas desordenadas, etc.). Además de esto, solo HEAD y algunas solicitudes GET (es decir, limitadas a solicitudes de archivos reales y, por lo tanto, con URL sin cadenas de consulta utilizadas como comando, etc.) podrían canalizarse en un modo seguro e idempotente.

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.9un recurso solicitado siempre se enviaba completo.HTTP/1.0HTTP/1.0 agregó encabezados para administrar los recursos almacenados en caché por el cliente para permitir solicitudes GET condicionales; en la práctica, un servidor tiene que devolver todo el contenido del recurso solicitado solo si el cliente no conoce la hora de su última modificación o si cambió desde la última respuesta completa a la solicitud GET. Uno de estos encabezados, "Codificación de contenido", se agregó para especificar si el contenido devuelto de un recurso estaba o no comprimido.Si la longitud total del contenido de un recurso no se conocía de antemano (es decir, porque se generó dinámicamente, etc.), el encabezado "Content-Length: number"no estaba presente en los encabezados HTTP y el cliente asumió que cuando el servidor cerró la conexión, el contenido había sido totalmente enviado. Este mecanismo no podía distinguir entre una transferencia de recursos completada con éxito y una interrumpida (debido a un error del servidor/red u otra cosa).HTTP/1.1HTTP/1.1 introducido:

• nuevos encabezados para administrar mejor la recuperación condicional de los 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 sabe de antemano su longitud (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) pieza(s) solicitada(s). Esto es útil para reanudar una descarga interrumpida (cuando un archivo es realmente grande), cuando solo una parte de un contenido debe mostrarse o agregarse 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/3Tanto HTTP/2 como HTTP/3 han mantenido las características mencionadas anteriormente de HTTP/1.1.

Autenticación HTTP

HTTP proporciona varios esquemas de autenticación, como la autenticación de acceso básica y la autenticación de acceso implícita, 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 entregar 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 puede ser utilizado por un servidor para desafiar la solicitud de un cliente y por un cliente para proporcionar información de autenticación.

El mecanismo anterior pertenece al protocolo HTTP y es administrado por el software HTTP del cliente y el servidor (si está configurado para requerir autenticación antes de permitir el acceso del cliente a uno o más recursos web), no por la aplicación web que generalmente usa una sesión de aplicación web.

Reinos de autenticación

La especificación de autenticación HTTP también proporciona una construcción arbitraria específica de la implementación para dividir aún más los recursos comunes a un URI raíz dado. La cadena de valor del reino, si está presente, se combina con el URI raíz canónico para formar el componente de espacio de protección del desafío. En efecto, esto permite que el servidor defina ámbitos de autenticación separados bajo un URI raíz.

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 múltiples solicitudes.

Algunas aplicaciones web necesitan administrar las sesiones de los usuarios, por lo que implementan estados o sesiones del lado del servidor, utilizando, por ejemplo, cookies HTTP o variables ocultas dentro de los formularios web.

Para iniciar una sesión de usuario de la aplicación, se debe realizar una autenticación interactiva a través del inicio de sesión de la aplicación web. Para detener una sesión de usuario, el usuario debe solicitar una operación de cierre de sesión. Este tipo de operaciones no utiliza la autenticación HTTP, sino una autenticación de aplicación web administrada personalizada.

Mensajes de solicitud HTTP/1.1

Los mensajes de solicitud son enviados por un cliente a un servidor de destino.

Solicitud de sintaxis

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

• una línea de solicitud, que consta del método de solicitud que distingue entre mayúsculas y minúsculas, un espacio, la URL solicitada, otro espacio, la versión del protocolo, un retorno de carro y un avance de línea, por ejemplo:

OBTENER /imágenes/logotipo.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 de los cuales consta del nombre del campo que no distingue entre mayúsculas y minúsculas, dos puntos, un espacio en blanco inicial opcional, el valor del campo, un espacio en blanco final opcional y termina con un retorno de carro y salto de línea, por ejemplo:

Anfitrión: www.ejemplo.com
Aceptar-Idioma: es

• una línea vacía, que consta de un retorno de carro y un salto 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.

Métodos de solicitud

HTTP define métodos (a veces denominados verbos, pero en ninguna parte de la especificación menciona verbo) para indicar la acción que se desea realizar en el recurso identificado. Lo que representa este recurso, 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 definió los métodos GET, HEAD y POST, y la especificación HTTP/1.1agregó cinco nuevos métodos: PUT, DELETE, CONNECT, OPTIONS y TRACE. Cualquier cliente puede utilizar 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, será tratado 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 romper 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. Esto contrasta con los nombres de campo de encabezado HTTP que no distinguen entre mayúsculas y minúsculas.OBTENEREl 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 se aplica a algunos otros métodos HTTP). Para recuperar recursos sin realizar cambios, se prefiere GET a POST, ya que se pueden abordar a través de una URL. Esto permite marcar y compartir y hace que las respuestas GET sean elegibles 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". Vea los métodos seguros a continuación.CABEZAEl método HEAD solicita que el recurso de destino transfiera una representación de su estado, como para una solicitud GET, pero sin los datos de representación incluidos en el cuerpo de la respuesta. Esto es útil para recuperar los metadatos de la representación en el encabezado de la respuesta, sin tener que transferir toda la representación. Los usos incluyen verificar 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).CORREOEl 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.PONEREl 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 de POST es que el cliente especifica la ubicación de destino en el servidor.ELIMINAREl método DELETE solicita que el recurso de destino elimine su estado.CONECTAREl método CONNECT solicita que el intermediario establezca un túnel TCP/IP al servidor de origen identificado por el destino de la solicitud. A menudo se usa para proteger las conexiones a través de uno o más servidores proxy HTTP con TLS. Consulte el método HTTP CONNECT.OPCIONESEl método OPTIONS solicita que el recurso de destino transfiera los métodos HTTP que admite. Esto se puede usar para verificar la funcionalidad de un servidor web solicitando '*' en lugar de un recurso específico.RASTROEl 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 corresponde) han realizado los intermediarios.PARCHEEl método PATCH solicita que el recurso de destino modifique su estado de acuerdo con la actualización parcial definida en la representación adjunta en la solicitud. Esto puede ahorrar ancho de banda al actualizar una parte de un archivo o documento sin tener que transferirlo por completo.

Todos los servidores web de uso 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.

Método de solicitud	RFC	La solicitud tiene un cuerpo de carga útil	La respuesta tiene un cuerpo de carga útil	Seguro	idempotente	almacenable en caché
OBTENER	RFC 7231	Opcional	Sí	Sí	Sí	Sí
CABEZA	RFC 7231	Opcional	No	Sí	Sí	Sí
CORREO	RFC 7231	Sí	Sí	No	No	Sí
PONER	RFC 7231	Sí	Sí	No	Sí	No
ELIMINAR	RFC 7231	Opcional	Sí	No	Sí	No
CONECTAR	RFC 7231	Opcional	Sí	No	No	No
OPCIONES	RFC 7231	Opcional	Sí	Sí	Sí	No
RASTRO	RFC 7231	No	Sí	Sí	Sí	No
PARCHE	RFC 5789	Sí	Sí	No	No	No

Métodos seguros

Un método de solicitud es seguro si una solicitud con ese método no tiene el 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 destinados a ser de solo lectura. Sin embargo, no excluyen los efectos secundarios, como agregar información de solicitud a un archivo de registro o cargar una cuenta de publicidad, ya que, por definición, no son solicitados por el cliente.

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, tales métodos no suelen ser utilizados por robots web conformes o rastreadores web; algunos que no se ajustan tienden a hacer solicitudes sin tener en cuenta el contexto o las consecuencias.

A pesar de la seguridad prescrita de las solicitudes GET, en la práctica, su manejo por parte del servidor no está limitado técnicamente de ninguna manera. La programación descuidada o deliberadamente irregular puede permitir que las solicitudes GET provoquen cambios no triviales en el servidor. Esto no se recomienda 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 de forma arbitraria, incluso usando GET, simplemente eliminaría el artículo. Un sitio web correctamente codificado requeriría un método DELETE o POST para esta acción, que los bots no maliciosos no realizarían.

Un ejemplo de esto que ocurrió en la práctica fue durante la breve versión beta de Google Web Accelerator, que precargaba URL arbitrarias en la página que estaba viendo un 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, luego de las críticas generalizadas.

Métodos idempotentes

Un método de solicitud es idempotentesi múltiples solicitudes idénticas con ese método tienen el mismo efecto que una sola solicitud de este 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 sucesivas solicitudes idénticas 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 extremo 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. Del mismo modo, 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 efectos adicionales, 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 haciendo clic de nuevo en un botón si no recibió 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 recargar 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 imponen 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 sea activada por un GET u otra solicitud. Sin embargo, hacerlo en contra de las recomendaciones puede tener consecuencias no deseadas, si un agente de usuario asume 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 reutilizarlas en el futuro. 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é.

Solicitar campos de encabezado

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.

Sintaxis de respuesta

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

• una línea de estado, que consta de la versión del protocolo, un espacio, el código de estado de la 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 Aceptar

• cero o más campos de encabezado de respuesta, cada uno de los cuales consta del nombre del campo que no distingue entre mayúsculas y minúsculas, dos puntos, un espacio en blanco inicial opcional, el valor del campo, un espacio en blanco final opcional y que termina 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 salto de línea;
• un cuerpo de mensaje opcional.

Códigos de estado de respuesta

En HTTP/1.0 y desde entonces, 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 de motivo textual (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 otros 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 se pueden reemplazar con "equivalentes locales" a discreción del desarrollador web. Si el código de estado indica un problema, la aplicación 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 podría 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)La solicitud fue recibida, continuando proceso.2XX(exitoso)La solicitud fue recibida, entendida y aceptada con éxito.3XX(redireccionamiento)Es necesario tomar más medidas 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 con una solicitud aparentemente válida.

Campos de encabezado de respuesta

Los campos de 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. Brindan información sobre el servidor o sobre un mayor acceso al recurso de destino o recursos relacionados.

Cada campo de encabezado de respuesta tiene un significado definido que se puede refinar aún más mediante la semántica del método de solicitud o el código de estado de respuesta.

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

A continuación se muestra una transacción HTTP de muestra entre un cliente HTTP/1.1 y un servidor HTTP/1.1 que se ejecuta en www.example.com, puerto 80.

Solicitud de cliente

GET  /  HTTP / 1.1 
Host:  www.example.com 
User-Agent:  Mozilla/5.0 
Aceptar:  text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 
Aceptar idioma:  en-GB,en;q=0.5 
Aceptar codificación:  gzip, deflate, br 
Conexión:  keep-alive

Una solicitud de cliente (que consiste en este caso en la línea de solicitud y algunos encabezados que pueden reducirse solo al "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 sola 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 oblicua) por lo general 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 
Content-Length:  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 " 
Aceptar-Rangos:  bytes 
Conexión:  cerrar

< html > 
  < encabezado > 
    < título > Una página de ejemplo </ título > 
  </ encabezado > 
  < cuerpo > 
    < p > Hola mundo, este es un documento HTML muy simple. </ p > 
  </ cuerpo > 
</ html >

El campo de encabezado ETag (etiqueta de entidad) se usa para determinar si una versión almacenada 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 "Accept-Ranges: bytes". Esto es útil si el cliente necesita que el servidor envíe solo ciertas partes 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.

La mayoría de las líneas de encabezado son opcionales, pero algunas son obligatorias. Cuando falta el encabezado "Content-Length: number"en una respuesta con un cuerpo de entidad, esto debe considerarse un error en HTTP/1.0, pero puede no ser 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 omitieron el encabezado "Content-Length"cuando no se conocía la longitud de la entidad del cuerpo al comienzo de la respuesta, por lo que la transferencia de datos al cliente continuó hasta que el servidor cerró el socket.

Se "Content-Encoding: gzip"puede usar para informar al cliente que la parte de la entidad del cuerpo de los datos transmitidos está comprimida por el algoritmo gzip.

Conexiones encriptadas

La forma más popular de establecer una conexión HTTP encriptada es HTTPS. También existen otros dos métodos para establecer una conexión HTTP cifrada: Protocolo seguro de transferencia de hipertexto y 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.

Protocolos similares

• El protocolo Gopher es un protocolo de entrega de contenido que fue desplazado 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 funciones relacionadas con la privacidad.