Protocolo de Transferencia de Hipertexto

Protocolo de aplicación para sistemas de información distribuidos, colaborativos e hipermedia

Protocolo de Transferencia de Hipertexto

Estándar internacional	RFC  1945 HTTP / 1.0 (1996) RFC  2616 HTTP / 1.1 (1999) RFC 7540 HTTP / 2 (2015) RFC 7541 Compresión de encabezado (2, 2015) RFC 7230 Sintaxis y enrutamiento de mensajes (1.1, 2014) RFC 7231 Semántica y contenido (1.1, 2014) RFC 7232 Solicitudes condicionales (1.1, 2014) RFC 7233 Solicitudes de rango (1.1, 2014) RFC 7234 Almacenamiento en caché (1.1, 2014)                Autenticación RFC 7235 (1.1, 2014)
Desarrollado por	inicialmente CERN ; IETF , W3C
Introducido	1991 ; Hace 30 años ( 1991 )

HTTP
Persistencia Compresión HTTPS QUIC
Métodos de solicitud
OPCIONES OBTENER CABEZA CORREO PONER ELIMINAR RASTRO CONECTAR PARCHE
Campos de encabezado
Galleta ETag Localización Referer HTTP DNT X-reenviado-para
Códigos de estado
301 Movido Permanentemente 302 Encontrado 303 Ver otros 403 Prohibido 404 No encontrado 451 No disponible por motivos legales
Métodos de control de acceso de seguridad
Autenticación de acceso básica Autenticación de acceso implícito
Vulnerabilidades de seguridad
Inyección de encabezado HTTP Contrabando de solicitudes HTTP División de respuesta HTTP Contaminación del parámetro HTTP
v t mi

Conjunto de protocolos de internet
Capa de aplicación
BGP DHCP (v6) DNS FTP HTTP HTTPS IMAP LDAP MGCP MQTT NNTP NTP MÚSICA POP PTP ONC / RPC RTP RTSP ROTURA sorbo SMTP SNMP SSH Telnet TLS / SSL XMPP más...
Capa de transporte
TCP UDP DCCP SCTP RSVP más...
Capa de internet
IP IPv4 IPv6 ICMP (v6) ECN IGMP IPsec más...
Capa de enlace
ARP NDP OSPF Túneles L2TP PPP MAC Ethernet Wifi DSL RDSI FDDI más...
v t mi

El Protocolo de transferencia de hipertexto ( HTTP ) es un protocolo de capa de aplicación para sistemas de información hipermedia distribuidos y colaborativos . ^[1] HTTP es la base de la comunicación de datos para la World Wide Web , donde los documentos de hipertexto incluyen hipervínculos a otros recursos a los que el usuario puede acceder fácilmente, por ejemplo con un clic del mouse o tocando la pantalla en un navegador web.

El desarrollo de HTTP fue iniciado por Tim Berners-Lee en el CERN en 1989. El desarrollo de las primeras solicitudes de HTTP para comentarios (RFC) fue un esfuerzo coordinado por el Grupo de trabajo de ingeniería de Internet (IETF) y el Consorcio World Wide Web (W3C), con trabajo luego se trasladó al IETF.

HTTP / 1 se documentó por primera vez (como versión 1.1) en 1997. ^[2] A partir de 2021, alrededor del 30% de los sitios web solo admiten HTTP / 1.

HTTP / 2 es una expresión más eficiente de la semántica de HTTP "on the wire", se publicó en 2015 y es utilizada por más del 50% de los sitios web; ahora es compatible con prácticamente todos los navegadores web ^[3] y los principales servidores web a través de Transport Layer Security (TLS) utilizando una extensión Application-Layer Protocol Negotiation (ALPN) ^[4] donde se requiere TLS 1.2 o más reciente. ^{[5] [6]}

HTTP / 3 es el sucesor propuesto de HTTP / 2, ^{[7] [8]} y 2/3 de los usuarios del navegador web (tanto en computadoras de escritorio como en dispositivos móviles) ya pueden usar HTTP / 3, en el 19.0% de los sitios web que ya lo admiten. ; utiliza UDP en lugar de TCP para el protocolo de transporte subyacente. Al igual que HTTP / 2, no hace obsoletas las versiones principales anteriores del protocolo. El soporte para HTTP / 3 se agregó a Cloudflare y Google Chrome en septiembre de 2019 (ya que está habilitado de forma predeterminada), ^{[9] [10]} y se puede habilitar en las versiones estables de Firefox ^[11] y Safari.

Descripción general técnica

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

HTTP funciona como un protocolo de solicitud-respuesta en el modelo informático cliente-servidor. Un navegador web , por ejemplo, puede ser el cliente y una aplicación que se ejecuta en una computadora que aloja un sitio 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 contenido solicitado en el cuerpo del mensaje.

Un navegador web es un ejemplo de 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, cuando es posible, para reducir el tráfico de la red. Los servidores proxy HTTP en los límites de la red privada pueden facilitar la comunicación para los clientes sin una dirección enrutable globalmente, al retransmitir mensajes con servidores externos.

HTTP es un protocolo de capa de aplicación diseñado dentro del marco del conjunto de protocolos de Internet . Su definición presupone un protocolo de capa de transporte subyacente y confiable , ^[12] y el Protocolo de control de transmisión (TCP) se usa comúnmente. Sin embargo, HTTP se puede adaptar para utilizar protocolos poco fiables como el Protocolo de datagramas de usuario (UDP), por ejemplo en HTTPU y el Protocolo simple de descubrimiento de servicios (SSDP).

Los recursos HTTP son identificados y ubicados en la red por localizadores uniformes de recursos (URL), utilizando los esquemas de identificadores uniformes de recursos (URI) http y https . Como se define en RFC 3986 , los URI se codifican como hipervínculos en documentos HTML , para formar documentos de hipertexto interconectados . 

HTTP / 1.1 es una revisión del HTTP original (HTTP / 1.0). En HTTP / 1.0 se realiza una conexión separada al mismo servidor para cada solicitud de recursos. HTTP / 1.1 puede reutilizar una conexión varias veces para descargar imágenes, scripts , hojas de estilo , etc. después de que se haya entregado la página. Por lo tanto, las comunicaciones HTTP / 1.1 experimentan menos latencia ya que el establecimiento de conexiones TCP presenta una sobrecarga considerable. ^[13]

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 los años 30 de Vannevar Bush del sistema " memex " de gestión y recuperació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 un navegador web basado en texto. Berners-Lee propuso por primera vez el proyecto "WorldWideWeb" en 1989, ahora conocido como World Wide Web.. La primera versión del protocolo tenía un solo método, a saber, GET, que solicitaba una página de un servidor. ^[14] La respuesta del servidor siempre fue una página HTML. ^[15]

La primera versión documentada de HTTP fue HTTP V0.9 (1991). Dave Raggett dirigió el HTTP Working Group (HTTP WG) en 1995 y quería 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 . ^{[16] [17]} RFC 1945 introdujo y reconoció oficialmente HTTP V1.0 en 1996. 

El HTTP WG planeaba publicar nuevos estándares en diciembre de 1995 ^[18] y el soporte para HTTP / 1.1 preestándar basado en el RFC 2068 en desarrollo (llamado HTTP-NG) fue rápidamente adoptado por los principales desarrolladores de navegadores a principios de 1996. Fin La adopción de los nuevos navegadores por parte de los usuarios 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 cumplían con HTTP 1.1. Esa misma empresa de alojamiento web informó que en junio de 1996, el 65% de todos los navegadores que acceden a sus servidores cumplían con HTTP / 1.1. ^[19] El estándar HTTP / 1.1 tal como se define en RFC 2068 se lanzó oficialmente en enero de 1997. Las mejoras y actualizaciones del estándar HTTP / 1.1 se publicaron bajo RFC   2616 en junio de 1999.

En 2007, se formó el Grupo de trabajo HTTP , en parte, para revisar y aclarar la especificación HTTP / 1.1. En junio de 2014, el WG publicó una especificación actualizada de seis partes que deja obsoleta la RFC 2616 : 

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

HTTP / 2 se publicó como RFC 7540 en mayo de 2015. 

Año	Versión HTTP
1991	0,9
1996	1.0
1997	1.1
2015	2.0
Borrador (2020)	3,0

Sesión HTTP

Una sesión HTTP es una secuencia de transacciones de solicitud-respuesta de red. Un cliente HTTP inicia una solicitud mediante el establecimiento de una conexión de Protocolo de control de transmisión (TCP) a un puerto en particular en un servidor (normalmente el puerto 80, ocasionalmente el puerto 8080; consulte la Lista de números de puerto TCP y UDP ). Un servidor HTTP que escucha en ese puerto espera el mensaje de solicitud de un cliente. Al recibir la solicitud, el servidor envía una línea de estado, como " HTTP / 1.1 200 OK ", y un mensaje propio. El cuerpo de este mensaje suele ser el recurso solicitado, aunque también se puede devolver un mensaje de error u otra información. ^[1]

Conexiones persistentes

Artículo principal: conexión persistente HTTP

En HTTP / 0.9 y 1.0, la conexión se cierra después de un solo par de solicitud / respuesta. En HTTP / 1.1 se introdujo un mecanismo de mantenimiento de vida, donde una conexión podía reutilizarse para más de una solicitud. Estas conexiones persistentes reducen la latencia de la solicitud de manera perceptible porque el cliente no necesita renegociar la conexión de protocolo de enlace de 3 vías de TCP 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 .

La versión 1.1 del protocolo también hizo mejoras de optimización del ancho de banda en HTTP / 1.0. Por ejemplo, HTTP / 1.1 introdujo la codificación de transferencia fragmentada para permitir que el contenido de las conexiones persistentes se transmita en lugar de almacenarlo en búfer. La canalización HTTP reduce aún más el tiempo de demora, lo que permite a los clientes enviar múltiples solicitudes antes de esperar cada respuesta. Otra adición al protocolo fue el servicio de bytes , donde un servidor transmite solo la parte de un recurso solicitado explícitamente por un cliente.

Estado de la sesión HTTP

HTTP es un protocolo sin estado . Un protocolo sin estado no requiere que el servidor HTTP retenga información o estado sobre cada usuario durante la duración de múltiples solicitudes. Sin embargo, algunas aplicaciones web implementan estados o sesiones del lado del servidor utilizando, por ejemplo, cookies HTTP o variables ocultas dentro de formularios web .

Autenticación HTTP

HTTP proporciona múltiples esquemas de autenticación, como la autenticación de acceso básica y la autenticación de acceso implícito, que operan 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 una solicitud de cliente y por un cliente para proporcionar información de autenticación. ^[20]

Reinos de autenticación

La especificación de autenticación HTTP también proporciona una construcción arbitraria y específica de la implementación para dividir aún más los recursos comunes a un URI raíz determinado . La cadena de valor de 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. ^[20]

Formato de mensaje

Ver también: Lista de campos de encabezado HTTP

El cliente envía solicitudes al servidor y el servidor envía respuestas .

Solicitar mensaje

El mensaje de solicitud consta de lo siguiente:

• una línea de solicitud (por ejemplo, GET /images/logo.png HTTP / 1.1 , que solicita un recurso llamado /images/logo.pngdesde el servidor)
• campos de encabezado de solicitud (por ejemplo, Accept-Language: en )
• una línea vacía
• un cuerpo de mensaje opcional

La línea de solicitud y otros campos de encabezado deben terminar con <CR> <LF> (es decir, un carácter de retorno de carro seguido de un carácter de avance de línea ). La línea vacía debe contener solo <CR> <LF> y ningún otro espacio en blanco . ^[21] En el protocolo HTTP / 1.1, todos los campos de encabezado excepto Host 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 . ^[22] 

Métodos de solicitud

Una solicitud HTTP / 1.1 realizada mediante telnet. La solicitud de mensaje, la respuesta sección de encabezado y cuerpo de la respuesta se resaltan.

HTTP define métodos (a veces denominados verbos , pero en ninguna parte de la especificación se menciona un verbo , ni OPTIONS o HEAD un 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 ^[23] definió los métodos GET, HEAD y POST y la especificación HTTP / 1.1 ^[24]se agregaron cinco nuevos métodos: OPCIONES, PONER, ELIMINAR, RASTREAR y CONECTAR. Al estar especificado en estos documentos, su semántica es bien conocida y se puede confiar en ella. Cualquier cliente puede utilizar cualquier método y el servidor se puede configurar para admitir cualquier combinación de métodos. Si un método es desconocido para un intermediario, se tratará como un método inseguro y no idempotente . No hay límite para la cantidad de métodos que se pueden definir y esto 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. ^{[25] [26]} Esto contrasta con los nombres de campo de encabezado HTTP que no distinguen entre mayúsculas y minúsculas. ^[27]

OBTENER

El método GET solicita una representación del recurso especificado. Las solicitudes que utilizan GET solo deben recuperar datos y no deben tener ningún otro efecto. (Esto también es cierto para algunos otros métodos HTTP). ^[1] El W3C ha publicado principios de orientación sobre esta distinción, diciendo: " El diseño de aplicaciones web debe basarse en los principios anteriores, pero también en las limitaciones relevantes". ^[28] Consulte los métodos seguros a continuación.

CABEZA

El método HEAD solicita una respuesta idéntica a la de una solicitud GET, pero sin el cuerpo de la respuesta. Esto es útil para recuperar metainformación escrita en encabezados de respuesta, sin tener que transportar todo el contenido.

CORREO

El método POST solicita que el servidor acepte la entidad incluida en la solicitud como un nuevo subordinado del recurso web identificado por el URI. Los datos POSTED pueden ser, por ejemplo, una anotación de recursos existentes; un mensaje para un tablón de anuncios, un grupo de noticias, una lista de correo o un hilo de comentarios; un bloque de datos que es el resultado de enviar un formulario web a un proceso de manejo de datos; o un elemento para agregar a una base de datos. ^[29]

PONER

El método PUT solicita que la entidad adjunta se almacene bajo el URI proporcionado . Si el URI se refiere a un recurso ya existente, se modifica; si el URI no apunta a un recurso existente, el servidor puede crear el recurso con ese URI. ^[30]

ELIMINAR

El método DELETE elimina el recurso especificado.

RASTRO

El método TRACE hace eco de la solicitud recibida para que un cliente pueda ver qué cambios (si los hay) o adiciones han realizado los servidores intermedios.

OPCIONES

El método OPTIONS devuelve los métodos HTTP que admite el servidor para la URL especificada . Esto se puede usar para verificar la funcionalidad de un servidor web solicitando '*' en lugar de un recurso específico.

CONECTAR

^[31] El método CONNECT convierte la conexión de solicitud en un túnel TCP / IP transparente, generalmente para facilitar lacomunicación encriptada SSL (HTTPS) a través de un proxy HTTP no encriptado. ^{[32] [33]} Consulte el método HTTP CONNECT .

PARCHE

El método PATCH aplica modificaciones parciales a un recurso. ^[34]

Todos los servidores HTTP de propósito general deben implementar al menos los métodos GET y HEAD, y la especificación considera que todos los demás métodos son opcionales. ^[35]

Métodos seguros

Algunos de los métodos (por ejemplo, GET, HEAD, OPTIONS y TRACE) se definen, por convención, como seguros , lo que significa que están destinados únicamente a la recuperación de información y no deben cambiar el estado del servidor. En otras palabras, no deberían tener efectos secundarios , más allá de efectos relativamente inofensivos como el registro , el almacenamiento en caché web, la publicación de anuncios publicitarios o el aumento de un contador web . Por lo tanto, la realización de solicitudes GET arbitrarias sin tener en cuenta el contexto del estado de la aplicación debe considerarse segura. Sin embargo, esto no es obligatorio por el estándar, y se reconoce explícitamente que no se puede garantizar.

Por el contrario, los métodos como POST, PUT, DELETE y PATCH están destinados a acciones que pueden causar efectos secundarios en el servidor o efectos secundarios externos como transacciones financieras o transmisión de correo electrónico . Por lo tanto, estos métodos no suelen ser utilizados por robots web o rastreadores web compatibles; 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á técnicamente limitado de ninguna manera. Por lo tanto, una programación descuidada o deliberada puede provocar cambios no triviales en el servidor. Esto se desaconseja, porque puede causar problemas para el almacenamiento en caché web , los motores de búsqueda y otros agentes automatizados, que pueden realizar 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. ^[36]

Un ejemplo de esto que ocurrió en la práctica fue durante la versión beta de Google Web Accelerator de corta duración , que precargó URL arbitrarias en la página que estaba viendo un usuario, lo que provocó que los registros se modificaran o eliminaran automáticamente en masa . La beta se suspendió solo unas semanas después de su primer lanzamiento, tras las críticas generalizadas. ^{[37] [36]}

Métodos y aplicaciones web idempotentes

Los métodos PUT y DELETE se definen como idempotentes , lo que significa que varias solicitudes idénticas deben tener el mismo efecto que una sola solicitud. Los métodos GET, HEAD, OPTIONS y TRACE, que se prescriben como seguros, también deben ser idempotentes, ya que HTTP es un protocolo sin estado . ^[1]

Por el contrario, el método POST no es necesariamente idempotente y, por lo tanto, enviar una solicitud POST idéntica varias veces puede afectar aún más el estado o causar más efectos secundarios (como transacciones financieras ). En algunos casos esto puede ser deseable, pero en otros casos esto podría deberse a un accidente, como cuando un usuario no se da cuenta de que su acción resultará en el envío de otra solicitud, o no recibió la retroalimentación adecuada de que su primera solicitud fue exitoso. Si bien los navegadores web pueden mostrar cuadros de diálogo de alerta para advertir a los usuarios en algunos casos en los que la recarga de 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. 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, ignorar esta recomendación puede tener consecuencias no deseadas si un agente de usuario supone que repetir la misma solicitud es seguro cuando no lo es.

Seguridad

El método TRACE se puede utilizar como parte de una clase de ataques conocidos como rastreo entre sitios ; por esa razón, un consejo de seguridad común es deshabilitarlo en la configuración del servidor. ^[38] Microsoft IIS admite un método propietario "TRACK", que se comporta de manera similar y que también se recomienda desactivar. ^[38]

Seguridad de los métodos HTTP

Método HTTP	RFC	La solicitud tiene cuerpo	La respuesta tiene cuerpo	A salvo	Idempotente	Almacenable en caché
OBTENER	RFC  7231	No	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

Mensaje de respuesta

El mensaje de respuesta consta de lo siguiente:

• una línea de estado que incluye el código de estado y el mensaje de motivo (por ejemplo, HTTP / 1.1 200 OK , que indica que la solicitud del cliente se realizó correctamente)
• campos de encabezado de respuesta (por ejemplo, tipo de contenido: texto / html )
• una línea vacía
• un cuerpo de mensaje opcional

La línea de estado y otros campos del encabezado deben terminar con <CR> <LF>. La línea vacía debe contener solo <CR> <LF> y ningún otro espacio en blanco . ^[21] Este requisito estricto para <CR> <LF> se relaja un poco dentro de los cuerpos de los mensajes para el uso consistente de otros saltos de línea del sistema como <CR> o <LF> solo. ^[39]

Códigos de estado

Consulte también: Lista de códigos de estado HTTP

En HTTP / 1.0 y desde entonces, la primera línea de la respuesta HTTP se llama línea de estado e incluye un código de estado numérico (como " 404 ") y una frase de motivo textual (como "No encontrado"). La forma en que el agente de usuario maneja la respuesta depende principalmente del código y, en segundo lugar, de los otros campos de encabezado de respuesta . Se pueden usar códigos de estado personalizados, ya que si el agente de usuario encuentra un código que no reconoce, puede usar el primer dígito del código para determinar la clase general de la respuesta. ^[40]

Las frases de motivo estándar son solo recomendaciones y pueden reemplazarse con "equivalentes locales" a discreción del desarrollador web . Si el código de estado indica un problema, el agente de usuario puede mostrar la frase de motivo al usuario para proporcionar más información sobre la naturaleza del problema. El estándar también permite que el agente de usuario intente interpretar la frase de motivo , aunque esto 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 código de estado HTTP se divide principalmente en cinco grupos para una mejor explicación de la solicitud y las respuestas entre el cliente y el servidor con el nombre:

• Informativo 1XX
• Exitoso 2XX
• Redireccionamiento 3XX
• Error del cliente 4XX
• Error del Servidor 5XX

Conexiones encriptadas

La forma más popular de establecer una conexión HTTP cifrada es HTTPS . ^[41] También existen otros dos métodos para establecer una conexión HTTP cifrada: Protocolo seguro de transferencia de hipertexto y el uso del encabezado de actualización HTTP / 1.1 para especificar una actualización a TLS. Sin embargo, el soporte del navegador para estos dos es casi inexistente. ^{[42] [43] [44]}

Sesión de ejemplo

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

Solicitud de cliente

GET  /  HTTP / 1.1 Host :  www.example.com

Una solicitud de cliente (que en este caso consiste en la línea de solicitud y solo un campo de encabezado) va seguida de una línea en blanco, de modo que la solicitud termina con un salto de línea doble, cada uno en forma de retorno de carro seguido de un avance de línea . El campo "Host" distingue entre varios nombres DNS que comparten una única dirección IP , lo que permite un alojamiento virtual basado en nombres . Si bien es opcional en HTTP / 1.0, es obligatorio en HTTP / 1.1. (Una "/" (barra) normalmente buscará 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 :  texto / html; charset = UTF-8 Contenido-Longitud :  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 >  < head >  < title > Una página de ejemplo </ title >  </ head >  < body >  < p > Hola mundo, este es un documento HTML muy simple. </ p >  </ cuerpo > </ html >

El campo de encabezado ETag (etiqueta de entidad) se utiliza para determinar si una versión en caché del recurso solicitado es idéntica a la versión actual del recurso en el servidor. Content-Type especifica el tipo de medio de Internet de los datos transmitidos por el mensaje HTTP, mientras que Content-Length indica su longitud en bytes. El servidor web HTTP / 1.1 publica su capacidad para responder a las solicitudes de ciertos rangos de bytes del documento configurando el campo Accept-Ranges: bytes . Esto es útil, si el cliente necesita tener solo ciertas porciones ^[45] de un recurso enviado por el servidor, lo que se llama servicio de bytes . Cuando Conexión: cerrarse envía, significa que el servidor web cerrará la conexión TCP inmediatamente después de la transferencia de esta respuesta.

La mayoría de las líneas de encabezado son opcionales. Cuando falta Content-Length, la longitud se determina de otras formas. La codificación de transferencia fragmentada utiliza un tamaño de fragmento de 0 para marcar el final del contenido. La codificación de identidad sin Content-Length lee el contenido hasta que se cierra el socket.

Se puede utilizar una codificación de contenido como gzip para comprimir los datos transmitidos.

Protocolos similares

• El protocolo Gopher es un protocolo de entrega de contenido que fue reemplazado por HTTP a principios de la década de 1990.
• El protocolo SPDY es una alternativa a HTTP desarrollado en Google , reemplazado por HTTP / 2 .

Ver también

HTTP
Persistencia Compresión HTTPS QUIC
Métodos de solicitud
OPCIONES OBTENER CABEZA CORREO PONER ELIMINAR RASTRO CONECTAR PARCHE
Campos de encabezado
Galleta ETag Localización Referer HTTP DNT X-reenviado-para
Códigos de estado
301 Movido Permanentemente 302 Encontrado 303 Ver otros 403 Prohibido 404 No encontrado 451 No disponible por motivos legales
Métodos de control de acceso de seguridad
Autenticación de acceso básica Autenticación de acceso implícito
Vulnerabilidades de seguridad
Inyección de encabezado HTTP Contrabando de solicitudes HTTP División de respuesta HTTP Contaminación del parámetro HTTP
v t mi

• Comparación de protocolos de transferencia de archivos
• Protocolo de aplicación restringida : un protocolo semánticamente similar a HTTP pero que utiliza mensajes UDP o similares a UDP destinados a dispositivos con capacidad de procesamiento limitada; reutiliza HTTP y otros conceptos de Internet como el tipo de medio de Internet y los enlaces web (RFC 5988) ^[46]
• Negociación de contenido
• Autenticación de acceso implícito
• Compresión HTTP
• HTTP / 2 : desarrollado por el grupo de trabajo del Protocolo de transferencia de hipertexto (httpbis) del IETF ^[47]
• HTTP-MPLEX: una mejora compatible con versiones anteriores de HTTP para mejorar el tiempo de recuperación de páginas y objetos web en redes congestionadas propuesto por Robert Mattson
• Lista de campos de encabezado HTTP
• Lista de códigos de estado HTTP
• Transferencia de estado representacional (REST)
• Objeto variante
• Caché web
• WebSocket

Referencias

1. Fielding, Roy T .; Gettys, James; Mogul, Jeffrey C .; Nielsen, Henrik Frystyk; Maestro, Larry; Leach, Paul J .; Berners-Lee, Tim (junio de 1999). Protocolo de transferencia de hipertexto: HTTP / 1.1 . IETF . doi : 10.17487 / RFC2616 . RFC 2616 .
2. En RFC 2068 . Esa especificación quedó obsoleta por RFC 2616 en 1999, que también fue reemplazada por RFC 7230 en 2014.   
3. "Puedo usar ... Tablas de soporte para HTML5, CSS3, etc." . caniuse.com . Consultado el 2 de junio de 2020 .
4. "Extensión de negociación de protocolo de capa de aplicación de seguridad de la capa de transporte (TLS)" . IETF. Julio de 2014. RFC 7301 . 
5. Belshe, M .; Peon, R .; Thomson, M. "Protocolo de transferencia de hipertexto versión 2, uso de funciones TLS" . Consultado el 10 de febrero de 2015 .
6. Benjamín, David. "Utilizando TLS 1.3 con HTTP / 2" . tools.ietf.org . Consultado el 2 de junio de 2020 . Esto reduce la barrera para la implementación de TLS 1.3, una importante mejora de seguridad con respecto a TLS 1.2.
7. Bishop, Mike (2 de febrero de 2021). "Protocolo de transferencia de hipertexto versión 3 (HTTP / 3)" . tools.ietf.org . Consultado el 7 de abril de 2021 .
8. Cimpanu, Catalin. "HTTP-over-QUIC será renombrado HTTP / 3 | ZDNet" . ZDNet . Consultado el 19 de noviembre de 2018 .
9. 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 .
10. "HTTP / 3: el pasado, el presente y el futuro" . El blog de Cloudflare . 2019-09-26 . Consultado el 30 de octubre de 2019 .
11. "Firefox Nightly admite HTTP 3 - General - Comunidad Cloudflare" . 2019-11-19 . Consultado el 23 de enero de 2020 .
12. "Operación general" . RFC 2616 . pag. 12. seg. 1.4. doi : 10.17487 / RFC2616 . RFC 2616 .
13. "Documentos HTTP clásicos" . W3.org. 1998-05-14 . Consultado el 1 de agosto de 2010 .
14. Berners-Lee, Tim. "Protocolo de transferencia de hipertexto" . Consorcio World Wide Web . Consultado el 31 de agosto de 2010 .
15. Tim Berners-Lee . "El HTTP original tal como se definió en 1991" . Consorcio World Wide Web . Consultado el 24 de julio de 2010 .
16. Raggett, Dave. "Biografía de Dave Raggett" . Consorcio World Wide Web . Consultado el 11 de junio de 2010 .
17. Raggett, Dave; Berners-Lee, Tim. "Grupo de trabajo de protocolo de transferencia de hipertexto" . Consorcio World Wide Web . Consultado el 29 de septiembre de 2010 .
18. Raggett, Dave. "Planes HTTP WG" . Consorcio World Wide Web . Consultado el 29 de septiembre de 2010 .
19. "HTTP / 1.1" . Entrada del glosario de Webcom.com . Archivado desde el original el 21 de noviembre de 2001 . Consultado el 29 de mayo de 2009 .
20. Fielding, Roy T .; Reschke, Julian F. (junio de 2014). Protocolo de transferencia de hipertexto (HTTP / 1.1): autenticación . IETF. doi : 10.17487 / RFC7235 . RFC 7235 .
21. "Mensaje HTTP" . RFC 2616 . pag. 31. seg. 4. doi : 10.17487 / RFC2616 . RFC 2616 .
22. "Semana Apache. HTTP / 1.1" . 090502 apacheweek.com
23. Berners-Lee, Tim; Fielding, Roy T .; Nielsen, Henrik Frystyk. "Definiciones de métodos" . Protocolo de transferencia de hipertexto: HTTP / 1.0 . IETF. págs. 30–32. segundo. 8. doi : 10.17487 / RFC1945 . RFC 1945 .
24. "Definiciones de métodos" . RFC 2616 . págs. 51–57. segundo. 9. doi : 10.17487 / RFC2616 . RFC 2616 .
25. "RFC-7210 sección 3.1.1" . Tools.ietf.org . Consultado el 26 de junio de 2019 .
26. "RFC-7231 sección 4.1" . Tools.ietf.org . Consultado el 26 de junio de 2019 .
27. "RFC-7230 sección 3.2" . Tools.ietf.org . Consultado el 26 de junio de 2019 .
28. Jacobs, Ian (2004). "URI, direccionabilidad y uso de HTTP GET y POST" . Hallazgo del Grupo de Arquitectura Técnica . W3C . Consultado el 26 de septiembre de 2010 .
29. "POST" . RFC 2616 . pag. 54. seg. 9.5. doi : 10.17487 / RFC2616 . RFC 2616 .
30. "PONER" . RFC 2616 . pag. 55. seg. 9.6. doi : 10.17487 / RFC2616 . RFC 2616 .
31. "CONECTAR" . Protocolo de transferencia de hipertexto: HTTP / 1.1 . IETF. Junio ​​de 1999. p. 57. seg. 9,9. doi : 10.17487 / RFC2616 . RFC 2616 . Consultado el 23 de febrero de 2014 .
32. Khare, Rohit; Lawrence, Scott (mayo de 2000). Actualización a TLS dentro de HTTP / 1.1 . IETF. doi : 10.17487 / RFC2817 . RFC 2817 .
33. "Nota de vulnerabilidad VU # 150227: las configuraciones predeterminadas del proxy HTTP permiten conexiones TCP arbitrarias" . US-CERT . 2002-05-17 . Consultado el 10 de mayo de 2007 .
34. Dusseault, Lisa; Snell, James M. (marzo de 2010). Método PATCH para HTTP . IETF. doi : 10.17487 / RFC5789 . RFC 5789 .
35. "Método" . RFC 2616 . pag. 36. seg. 5.1.1. doi : 10.17487 / RFC2616 . RFC 2616 .
36. Ediger, Brad (21 de diciembre de 2007). Carriles avanzados: creación de aplicaciones web de potencia industrial en un tiempo récord . O'Reilly Media, Inc. pág. 188. ISBN 978-0596519728. Un error común es usar GET para una acción que actualiza un recurso. [...] Este problema llegó al ojo público de Rails en 2005, cuando se lanzó Google Web Accelerator.
37. Cantrell, Christian (1 de junio de 2005). "¿Qué hemos aprendido del Acelerador web de Google?" . Blogs de Adobe . Adobe. Archivado desde el original el 19 de agosto de 2017 . Consultado el 19 de noviembre de 2018 .
38. "Seguimiento de sitios cruzados" . OWASP . Consultado el 22 de junio de 2016 .
39. "Canonicalización y valores predeterminados de texto" . RFC 2616 . segundo. 3.7.1. doi : 10.17487 / RFC2616 . RFC 2616 .
40. "Línea de estado" . RFC 2616 . pag. 39. seg. 6.1. doi : 10.17487 / RFC2616 . RFC 2616 .
41. Canavan, John (2001). Fundamentos de la seguridad de las redes . Norwood, MA: Artech House. págs. 82–83. ISBN 9781580531764.
42. Zalewski, Michal. "Manual de seguridad del navegador" . Consultado el 30 de abril de 2015 .
43. "Problema de Chromium 4527: implementar RFC 2817: Actualización a TLS dentro de HTTP / 1.1" . Consultado el 30 de abril de 2015 .
44. "Error de Mozilla 276813 - [RFE] Soporte de actualización RFC 2817 / TLS para HTTP 1.1" . Consultado el 30 de abril de 2015 .
45. Luotonen, Ari; Franks, John (22 de febrero de 1996). Extensión de recuperación de rango de bytes a HTTP . IETF. ID borrador-ietf-http-range-retrieval-00.
46. Nottingham, Mark (octubre de 2010). Enlace web . IETF. doi : 10.17487 / RFC5988 . RFC 5988 .
47. "Protocolo de transferencia de hipertexto Bis (httpbis) - Carta" . IETF. 2012.

Enlaces externos

Wikimedia Commons tiene medios relacionados con el Protocolo de transferencia de hipertexto .

• "Historial de cambios para HTTP" . W3.org . Consultado el 1 de agosto de 2010 . Un historial técnico detallado de HTTP.
• "Problemas de diseño para HTTP" . W3.org . Consultado el 1 de agosto de 2010 . Problemas de diseño de Berners-Lee cuando estaba diseñando el protocolo.
• HTTP 0.9: implementado en 1991