Protocolo de Transferencia de Hipertexto

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 HTTP para comentarios (RFC) 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ó completamente (como versión 1.0) en 1996. Evolucionó (como versión 1.1) en 1997 y luego sus especificaciones se actualizaron en 1999, 2014 y 2022.

Más del 80 % de los sitios web utilizan su variante segura denominada HTTPS.

HTTP/2, publicado en 2015, proporciona una expresión más eficiente de la semántica de HTTP 'en el cable'. Ahora lo utiliza el 41 % de los sitios web y es compatible con casi todos los navegadores web (más del 97 % de los usuarios). También es compatible con los principales servidores web sobre seguridad de la capa de transporte (TLS) mediante una extensión de negociación de protocolo de capa de aplicación (ALPN) donde se requiere TLS 1.2 o más reciente.

HTTP/3, el sucesor de HTTP/2, se publicó en 2022. Ahora lo utiliza más del 25 % de los sitios web y es compatible con muchos navegadores web (más del 75 % 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. HTTP/3 tiene una latencia más baja para las páginas web del mundo real, si está habilitado en el servidor, se carga más rápido que con HTTP/2 e incluso más rápido que HTTP/1.1, en algunos casos más de 3 veces más rápido que HTTP/1.1 (que sigue siendo comúnmente solo habilitado).

Resumen técnico

URL que comienza con el esquema HTTP y la etiqueta de nombre de dominio WWW

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 intermedios de la red 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 paso a paso, mientras que otros encabezados HTTP se administran al final. -to-end (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's) 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 HTTP/1.1, en cambio, 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.).

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:

• utilizar una representación binaria comprimida de metadatos (cabezas HTTP) en lugar de uno textual, de modo que los encabezados requieren mucho menos espacio;
• utilizar una única conexión TCP/IP (generalmente encriptada) por dominio del servidor accedido en lugar de 2 a 8 conexiones TCP/IP;
• utilizar una o más secuencias bidireccionales por conexión TCP/IP en las que las solicitudes y respuestas HTTP se descomponen y transmiten en paquetes pequeños para casi resolver el problema de la HOLB (cabeza de bloqueo de línea).
• añadir una capacidad de empuje para permitir que la aplicación del servidor envíe datos a los clientes cuando se disponga de nuevos datos (sin obligar a los clientes a solicitar periódicamente nuevos datos al servidor utilizando métodos de votación).

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

Historia

Tim Berners-Lee

El término hipertexto fue acuñado por Ted Nelson en 1965 en el Proyecto Xanadu, que a su vez se inspiró en la visión de Vannevar Bush de la década de 1930 de la recuperación y gestión de información basada en microfilmes "memex" 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 diseñó HTTP para ayudar con la adopción de su otra idea: la "WorldWideWeb" proyecto, que se propuso por primera vez 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

HTTP/0.9

En 1991, la primera versión oficial documentada de HTTP fue escrita como documento claro, de menos de 700 palabras de largo, y esta versión fue nombrada HTTP/0.9. HTTP/0.9 solo admite el método GET, permitiendo a los clientes recuperar únicamente documentos HTML del servidor, pero no apoyando ningún otro formato de archivo o carga de información.

HTTP/1.0-draft

Desde 1992, se escribió un nuevo documento para especificar la evolución del protocolo básico hacia su próxima versión completa. Soportó tanto el método de solicitud simple de la versión 0.9 como la solicitud completa GET que incluyó la versión HTTP cliente. Este fue el primero de los muchos proyectos no oficiales de HTTP/1.0 que precedieron a la labor final sobre HTTP/1.0.

W3C HTTP Working Group

Después de haber decidido que se requerían nuevas características del protocolo HTTP y que tenían que estar plenamente documentados como RFC oficiales, a principios de 1995 se constituyó el Grupo de Trabajo HTTP (HTTP WG, dirigido por Dave Raggett) con el objetivo de estandarizar y ampliar el protocolo con operaciones ampliadas, negociación ampliada, metáfora más rica, vinculada con un protocolo de seguridad que se hizo más eficiente al agregar métodos adicionales y campos de encabezado.

The HTTP WG planned to revise and publish new versions of the protocol as HTTP/1.0 and HTTP/1.1 within 1995, but, because of the many revisions, that timeline durated much more than one year.

El HTTP WG planeó también especificar una versión muy futura de HTTP llamada HTTP-NG (HTTP Next Generation) que habría resuelto todos los problemas restantes, de versiones anteriores, relacionados con rendimientos, respuestas de baja latencia, etc. pero este trabajo comenzó sólo unos pocos años después y nunca se completó.

HTTP/1.0

En mayo de 1996, RFC 1945 fue publicada como una revisión final HTTP/1.0 de lo que se había utilizado en 4 años anteriores como un HTTP/1.0-draft pre-estándar que ya fue utilizado por muchos navegadores web y servidores web.

In early 1996 developers started to even include unofficial extensions of the HTTP/1.0 protocol (i.e. keep-alive connections, etc.) into their products by using drafts of the forthcoming HTTP/1.1 especificaciones.

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 por HTTP/1.1 pre-estándar. La adopción del usuario final de las nuevas versiones de los navegadores y servidores fue rápida. En marzo de 1996, una empresa de hospedaje web informó que más del 40% de los navegadores utilizados en Internet utilizaban el nuevo encabezado HTTP/1.1 "Host" para permitir el alojamiento virtual. Esa misma compañía de hospedaje web informó que para junio de 1996, el 65% de todos los navegadores que acceden a sus servidores eran pre-estándar HTTP/1.1 compatibles.

En enero de 1997, RFC 2068 fue publicado oficialmente como especificaciones HTTP/1.1.

En junio de 1999 se lanzó RFC 2616 para incluir todas las mejoras y actualizaciones basadas en las especificaciones anteriores (obsoletos) HTTP/1.1.

W3C HTTP-NG Working Group

Resumir el antiguo plan de 1995 del anterior Grupo de Trabajo sobre el HTTP, en 1997 HTTP-NG Working Group se formó para desarrollar un nuevo protocolo HTTP llamado HTTP-NG (HTTP New Generation). Se elaboraron algunas propuestas / borradores para el nuevo protocolo de uso de múltiples 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.

IETF HTTP Working Group restarted

En 2007 se reanudó el Grupo de Trabajo HTTP (HTTP WG bis o HTTPbis) para revisar y aclarar las especificaciones anteriores HTTP/1.1 y en segundo lugar para escribir y perfeccionar las especificaciones futuras HTTP/2 (nombradas httpbis).

SPDY: un protocolo HTTP no oficial desarrollado por Google

En 2009, Google, una empresa privada, anunció que había desarrollado y probado un nuevo protocolo binario HTTP llamado SPDY. El objetivo implícito era acelerar mucho el tráfico web (especialmente entre futuros navegadores web y sus servidores).

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 principales navegadores web.

Algunas de las ideas sobre múltiples corrientes de HTTP sobre una única conexión TCP/IP fueron tomadas de diversas fuentes, entre ellas la labor del Grupo de Trabajo W3C HTTP-NG.

HTTP/2

En enero y marzo de 2012, el Grupo de Trabajo HTTP (HTTPbis) anunció la necesidad de comenzar a centrarse en un nuevo protocolo HTTP/2 (mientras termina 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 fue publicado como RFC 7540 y adoptado rápidamente por todos los navegadores web que ya soportan SPDY y más lentamente por servidores web.

Actualizaciones de 2014 a HTTP/1.1

En junio de 2014, el Grupo de Trabajo HTTP publicó una actualización de seis partes HTTP/1.1 especificación obsoleta RFC 2616:

• RFC 7230, HTTP/1.1: Sintaxis del mensaje y enrutamiento
• 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: Caching
• RFC 7235, HTTP/1.1: Autenticación

HTTP/0.9 Deprecation

En RFC 7230 Apéndice-A, HTTP/0.9 fue deprecado para servidores compatibles con la versión HTTP/1.1 (y superior):

Puesto que HTTP/0.9 no apoyó los campos de cabecera en una solicitud, no hay ningún mecanismo para que apoye los hosts virtuales basados en nombres (selección de recursos mediante inspección del campo de cabecera de Host). Cualquier servidor que implemente hosts virtuales basados en nombres debe desactivar soporte para HTTP/0.9. La mayoría de las solicitudes que parecen ser HTTP/0.9 son, de hecho, solicitudes de HTTP/1.x mal construidas causadas por un cliente que no codifica adecuadamente el objetivo de solicitud.

Desde 2016 muchos gestores de productos y desarrolladores de agentes de usuario (browsers, etc.) y servidores web han comenzado a planear gradualmente depreparar y desestimar el soporte para protocolo HTTP/0.9, principalmente por las siguientes razones:

• es tan simple que un documento RFC nunca fue escrito (hay sólo el documento original);
• no tiene cabeceras HTTP y carece de muchas otras características que hoy en día son necesarias por razones de seguridad mínimas;
• no se ha generalizado desde 1999..2000 (a causa de HTTP/1.0 y HTTP/1.1) y es comúnmente utilizado sólo por algún hardware de red muy antiguo, es decir, routers, etc.

HTTP/3

En 2020, los primeros borradores HTTP/3 fueron publicados y los principales navegadores web y servidores web comenzaron a adoptarlo.

El 6 de junio de 2022, IETF estandarizó HTTP/3 como RFC 9114.

Actualizaciones y refactorización en 2022

En junio de 2022, se publicó un lote de RFCs, deprecayendo muchos de los documentos anteriores e introduciendo algunos cambios menores y una refactorización de la descripción de la semántica HTTP en un documento separado.

• RFC 9110, HTTP Semantics
• RFC 9111, HTTP Caching
• RFC 9112, HTTP/1.1
• RFC 9113, HTTP/2
• RFC 9114, HTTP/3 (véase también la sección anterior)
• RFC 9204, QPACK: Compresión de campo para HTTP/3
• RFC 9218, Priorización extensible Esquema para HTTP

Intercambio de datos HTTP

HTTP es un protocolo de nivel de aplicación sin estado y requiere una conexión de transporte de red confiable para intercambiar datos entre el cliente y el servidor. 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 del 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 establece 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.1 también agregó la canalización HTTP para reducir aún más el tiempo de retraso al usar conexiones persistentes al permitir que los clientes envíen múltiples solicitudes antes de esperar cada respuesta. Esta optimización nunca se consideró realmente segura porque algunos servidores web y muchos servidores proxy, especialmente 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 cadena de consulta utilizada como comando, etc.) podrían canalizarse en un modo seguro e idempotente. Después de muchos años de luchar 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 también debido a la adopción anunciada de HTTP/2.

HTTP/2 amplió el uso de conexiones persistentes al multiplexar muchas solicitudes/respuestas simultáneas a través de una única conexión TCP/IP.

HTTP/3 no utiliza conexiones TCP/IP sino QUIC + UDP (ver también: descripción técnica).

Optimizaciones de recuperación de contenido

HTTP/0.9

a requested resource was always sent entirely.

HTTP/1.0

HTTP/1.0 agregó encabezados para gestionar recursos caché por cliente para permitir solicitudes condicionales de GET; en la práctica un servidor tiene que devolver todo el contenido del recurso solicitado sólo si su último tiempo modificado no es conocido por el cliente o si cambió desde la última respuesta completa a la solicitud de GET. Uno de estos encabezados, "Content-Encoding", fue añadido para especificar si el contenido devuelto de un recurso fue o no fue comprimido.

Si la longitud total del contenido de un recurso no se conocía por adelantado (es decir, porque se generó dinámicamente, etc.) entonces 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 enviado por completo. Este mecanismo no podía distinguir entre una transferencia de recursos exitosamente completada y una interrumpida (a causa de un error de servidor / red o algo más).

HTTP/1.1

HTTP/1.1 presentado:

• nuevos encabezados para gestionar mejor la recuperación condicional de recursos caché.
• codificación de transferencia desmontada para permitir que el contenido se transmita en pedazos con el fin de enviarlo de forma fiable incluso cuando el servidor no sabe de antemano su longitud (es decir, porque se genera dinámicamente, etc.).
• byte range serving, where a client can request only one or more portions (ranges of bytes) of a resource (i.e. the first part, a part in the middle or in the end of the entire content, etc.) and the server usually sends only the requested part(s). Esto es útil para reanudar una descarga interrumpida (cuando un archivo es realmente grande), cuando sólo una parte de un contenido tiene que ser mostrado o agregado dinámicamente a la parte ya visible por un navegador (es decir, sólo los primeros o siguientes comentarios n de una página web) para ahorrar tiempo, ancho de banda y recursos del sistema, etc.

HTTP/2, HTTP/3

Tanto HTTP/2 como HTTP/3 han mantenido las características mencionadas anteriormente de HTTP/1.1.

Autenticación HTTP

HTTP proporciona 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.

Los mecanismos de autenticación descritos anteriormente pertenecen al protocolo HTTP y son administrados por el software HTTP de cliente y 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 aplicación web. sesión.

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 determinado. 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 sesiones de usuario, por lo que implementan estados, o sesiones del lado del servidor, utilizando, por ejemplo, cookies HTTP o variables ocultas dentro de 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:

• a línea de solicitud, que consiste en el método de solicitud sensible al caso, un espacio, la URL solicitada, otro espacio, la versión del protocolo, una devolución de carro y una alimentación de línea, por ejemplo:

Obtener /images/logo.png HTTP/1.1

• cero o más campos de cabecera de solicitud (al menos 1 o más cabeceras en caso de HTTP/1.1), cada uno consistente en el nombre de campo insensible en caso de caso, un colon, el espacio blanco líder opcional, el valor de campo, un espacio blanco de seguimiento opcional y terminando con un retorno de carro y una alimentación de línea, por ejemplo:

Host: www.example.com
Accept-Language: en

• una línea vacía, que consiste en un retorno de carro y una alimentación de línea;
• un cuerpo de mensaje opcional.

En el protocolo HTTP/1.1, todos los campos de encabezado excepto Host: hostname son 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

Una solicitud HTTP/1.1 hecha con telnet. Se destaca el mensaje de solicitud, la sección de encabezado de respuesta y el órgano de respuesta.

HTTP define métodos (a veces denominados verbos, pero en ninguna parte de la especificación menciona verbo) para indicar la acción deseada que se 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.1 agregó 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.

#

El método GET solicita que el recurso objetivo transfiera una representación de su estado. Obtener solicitudes sólo debe recuperar datos y no debe tener ningún otro efecto. (Esto también es cierto de algunos otros métodos HTTP.) Para recuperar recursos sin hacer cambios, GET es preferido sobre POST, ya que pueden ser abordados a través de una URL. Esto permite marcar y compartir y hace que las respuestas de GET elegibles para caching, 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 ser informado por los principios anteriores, pero también por las limitaciones pertinentes". Vea métodos seguros abajo.

HEAD

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

POST

El método POST solicita que el proceso de recursos objetivo la representación adjunta en la solicitud de acuerdo con la semántica del recurso objetivo. Por ejemplo, se utiliza para enviar un mensaje a un foro de Internet, suscribirse a una lista de correo, o completar una transacción de compras en línea.

PUT

El método PUT solicita que el recurso objetivo cree o actualice su estado con el estado definido por la representación adjunta en la solicitud. Una distinción de POST es que el cliente especifica la ubicación de destino en el servidor.

DELETE

El método DELETE solicita que el recurso objetivo borre su estado.

CONNECT

El método CONNECT pide que el intermediario establezca un túnel TCP/IP al servidor de origen identificado por el objetivo de solicitud. A menudo se utiliza para asegurar conexiones a través de uno o más proxies HTTP con TLS. Vea el método HTTP CONNECT.

OPCIONES

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

Objetivo

El método TRACE solicita que el recurso objetivo transfiera la solicitud recibida en el órgano de respuesta. De esa manera un cliente puede ver qué (si hay) cambios o adiciones han sido hechos por intermediarios.

PATCH

El método PATCH solicita que el recurso objetivo modifique su estado de acuerdo con la actualización parcial definida en la representación adjunta en la solicitud. Esto puede guardar ancho de banda actualizando una parte de un archivo o documento sin tener que transferirlo por completo.

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

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 idempotente si varias solicitudes idénticas con ese método tienen el mismo efecto que una sola solicitud. 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 extremo 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, p. las solicitudes duplicadas después de una solicitud exitosa no tendrán ningún 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 cachear 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:

• a línea de estado, que consiste en la versión del protocolo, un espacio, el código de estado de respuesta, otro espacio, una frase razón posiblemente vacía, un retorno de carro y una alimentación de línea, por ejemplo:

HTTP/1.1 200 OK

• cero o más campos de cabecera de respuesta, cada uno compuesto por el nombre de campo insensible de caso, un colon, el espacio blanco líder opcional, el valor de campo, un espacio blanco de seguimiento opcional y terminando con un retorno de carro y una alimentación de línea, por ejemplo:

Tipo de contenido: texto/html

• una línea vacía, que consiste en un retorno de carro y una alimentación 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& #34;) y una frase de razón 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 motivos 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 razón 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 razón, 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 razón son legible por humanos.

El primer dígito del código de estado define su clase:

1XX (informacional)

The request was received, continuing process.

2XX (suficiente)

The request was successfully received, understood, and accepted.

3XX (redirección)

Es necesario adoptar nuevas medidas para completar la solicitud.

4XX (error de cliente)

La solicitud contiene mala sintaxis o no se puede cumplir.

5XX (error del servidor)

El servidor no cumplió 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 del cliente

# / HTTP/1.1Host: www.example.comUser-Agent: Mozilla/5.0Aceptar: texto/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: en-GB,en;q=0.5Aceptación: gzip, deflate, brConexión: mantener la calma

Una solicitud de cliente (que consiste en este caso en la línea de solicitud y algunos encabezados que se pueden reducir solo al encabezado "Host: hostname") va seguida de un espacio en blanco línea, de modo que la solicitud finalice con un doble final de línea, cada uno en forma de retorno de carro seguido de un salto de línea. El valor del encabezado "Host: hostname" 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 OKFecha: Mon, 23 de mayo de 2005 22:38:34 GMTTipo de contenido: texto/html; charset=UTF-8Content-Length: 155Last-Modified: Miércoles, 08 de enero de 2003 23:11:55 GMTServidor: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)ETag: "3f80f-1b6-3e1cb03b"Accept-Ranges: bytesConexión: cerca.html■ .cabeza■ .Título■Una página de ejemploc)Título■ c)cabeza■ .cuerpo■ .p■Hola World, este es un documento HTML muy simple.c)p■ c)cuerpo■c)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 las 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 se envía "Connection: close", 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 que no sea un error en HTTP /1.1 si el encabezado "Transfer-Encoding: chunked" está presente. La codificación de transferencia fragmentada utiliza un tamaño de fragmento de 0 para marcar el final del contenido. Algunas implementaciones antiguas de HTTP/1.0 omitieron el encabezado "Content-Length" cuando no se conocía la longitud de la entidad del cuerpo al comienzo de la respuesta y, por lo tanto, la transferencia de datos a el cliente continuó hasta que el servidor cerró el socket.

Se puede usar un "Codificación de contenido: gzip" 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 cifrada 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 contenidos que fue desplazado por HTTP a principios del decenio de 1990.
• El protocolo SPDY es una alternativa a HTTP desarrollada en Google, superada por HTTP/2.
• El protocolo Gemini es un protocolo inspirado en Gopher que manda características relacionadas con la privacidad.