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 , colaborativos y distribuidos . [1] HTTP es la base de la comunicación de datos para la World Wide Web , donde los documentos de hipertexto incluyen hipervínculos a otros recursos a los que el usuario puede acceder fácilmente, por ejemplo, haciendo clic con el mouse o tocando la pantalla de un navegador web.
El desarrollo de HTTP fue iniciado por Tim Berners-Lee en el CERN en 1989 y se resumió en un documento simple que describe el comportamiento de un cliente y un servidor usando la primera versión de HTTP, denominada 0.9. [2] Esa versión se desarrolló posteriormente y finalmente se convirtió en la pública 1.0. [3]
El desarrollo de las primeras solicitudes de comentarios (RFC) HTTP comenzó unos años más tarde en un esfuerzo coordinado por el Grupo de Trabajo de Ingeniería de Internet (IETF) y el Consorcio World Wide Web (W3C), y el trabajo se trasladó posteriormente al IETF.
HTTP/1 se finalizó y documentó completamente (como versión 1.0) en 1996. [4] Evolucionó (como versión 1.1) en 1997 y luego sus especificaciones se actualizaron en 1999, 2014 y 2022. [5]
Su variante segura denominada HTTPS es utilizada por más del 85% de los sitios web. [6] HTTP/2 , publicado en 2015, proporciona una expresión más eficiente de la semántica de HTTP "en el cable". En enero de 2024, [update]lo utilizan el 36 % de los sitios web [7] y lo admiten casi todos los navegadores web (más del 98 % de los usuarios). [8] También es compatible con los principales servidores web a través de Transport Layer Security (TLS) utilizando una extensión de negociación de protocolo de capa de aplicación (ALPN) [9] donde se requiere TLS 1.2 o posterior. [10] [11]
HTTP/3 , el sucesor de HTTP/2, se publicó en 2022. [12] Actualmente se utiliza en el 28 % de los sitios web [13] y es compatible con la mayoría de los navegadores web, es decir, (al menos parcialmente) con el 97 % de los navegadores web. navegadores web. [14] 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 , [15] [16] y también está habilitada en Firefox . [17] HTTP/3 tiene una latencia más baja para 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 todavía normalmente solo está habilitado). [18]
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 , denominado servidor web , que se ejecuta en una computadora que aloja uno o más sitios web puede ser el servidor . El cliente envía un mensaje de solicitud HTTP al servidor. El servidor, que proporciona recursos como archivos HTML y otro contenido o realiza otras funciones en nombre del cliente, devuelve un mensaje de respuesta al cliente. La respuesta contiene información sobre el estado de finalización de la solicitud y también puede contener contenido solicitado en el cuerpo del mensaje.
Un navegador web es un ejemplo de agente de usuario (UA). Otros tipos de agente 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 permitan las comunicaciones entre clientes y servidores. Los sitios web con mucho 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 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.
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 sólo por el cliente de origen y por el servidor web de destino).
HTTP es un protocolo de capa de aplicación diseñado dentro del marco del conjunto de protocolos de Internet . Su definición supone un protocolo de capa de transporte subyacente y confiable . [19] En la última versión HTTP/3 , el Protocolo de control de transmisión (TCP) ya no se usa, pero las versiones anteriores aún se usan más y usan más comúnmente TCP. También se han adaptado para utilizar protocolos no confiables como el Protocolo de datagramas de usuario (UDP), en el que HTTP/3 también (indirectamente) siempre se basa, por ejemplo en HTTPU y el Protocolo simple de descubrimiento de servicios (SSDP).
Los recursos HTTP se identifican y ubican en la red mediante localizadores uniformes de recursos (URL), utilizando los esquemas de identificadores uniformes de recursos (URI) http y https . Como se define en RFC 3986, los URI se codifican como hipervínculos en documentos HTML , para formar documentos de hipertexto interconectados .
En HTTP/1.0 se realiza una conexión TCP independiente al mismo servidor para cada solicitud de recurso. [20]
En cambio, en HTTP/1.1 se puede reutilizar una conexión TCP para realizar múltiples solicitudes de recursos (es decir, páginas HTML, marcos, imágenes, scripts , hojas de estilo , etc.). [21] [22]
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 mucho tráfico. [23]
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 orden:
Por lo tanto, las comunicaciones HTTP/2 experimentan mucha menos latencia y, en la mayoría de los casos, velocidades incluso más altas que las comunicaciones HTTP/1.1.
HTTP/3 es una revisión del HTTP/2 anterior para utilizar protocolos de transporte QUIC + UDP en lugar de TCP. Antes de esa versión, se utilizaban conexiones TCP/IP; pero ahora, sólo se utiliza la capa IP (en la que se basa UDP, al igual que TCP). Esto mejora ligeramente la velocidad media de las comunicaciones y evita el problema ocasional (muy raro) de congestión de la conexión TCP que puede bloquear o ralentizar temporalmente el flujo de datos de todos sus flujos (otra forma de " bloqueo de cabecera de línea ").
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 " Como podemos pensar ". ". 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: el proyecto "WorldWideWeb", propuesto por primera vez en 1989, ahora conocido como World Wide Web .
El primer servidor web entró en funcionamiento en 1990. [25] [26] El protocolo utilizado tenía un solo método, a saber, GET, que solicitaría una página de un servidor. [27] La respuesta del servidor siempre fue una página HTML. [2]
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 inspección del campo de encabezado del 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 codificó correctamente el destino de la solicitud.
HTTP es un protocolo a nivel de aplicación sin estado y requiere una conexión de transporte de red confiable para intercambiar datos entre el cliente y el servidor. [19] En las implementaciones HTTP, las conexiones TCP/IP se utilizan utilizando puertos conocidos (normalmente el puerto 80 si la conexión no está cifrada o el puerto 443 si la conexión está cifrada; consulte también Lista de números de puerto TCP y UDP ). [43] [44] En HTTP/2, se utiliza una conexión TCP/IP más múltiples canales de protocolo. En HTTP/3, se utiliza el protocolo de transporte de aplicaciones QUIC sobre UDP.
Los datos se intercambian a través de una secuencia de mensajes de solicitud-respuesta que se intercambian mediante una conexión de transporte de capa de sesión . [19] 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 mensaje de solicitud HTTP. Al recibir la solicitud, el servidor devuelve un mensaje de respuesta HTTP, que incluye encabezados más un cuerpo si es necesario. El cuerpo de este mensaje de respuesta 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 al cliente. [21]
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 que se haya enviado una respuesta. [nota 3]
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. Estas conexiones persistentes reducen perceptiblemente la latencia de las solicitudes porque el cliente no necesita renegociar la conexión TCP 3-Way-Handshake después de que se haya enviado la primera solicitud. Otro efecto secundario positivo es que, en general, la conexión se vuelve más rápida con el tiempo debido al mecanismo de inicio lento de TCP .
HTTP/1.1 también agregó canalización HTTP para reducir aún más el tiempo de demora cuando se usan conexiones persistentes al permitir a los clientes enviar múltiples solicitudes antes de esperar cada respuesta. Esta optimización nunca se consideró realmente segura porque algunos servidores web y muchos servidores proxy , especialmente servidores proxy transparentes ubicados en Internet/ Intranets entre clientes y servidores, no manejaban las solicitudes canalizadas correctamente (sólo atendían la primera solicitud descartando las demás, cerraban 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 las solicitudes HEAD y algunas GET (es decir, limitadas a solicitudes de archivos reales y, por lo tanto, con URL sin cadena de consulta utilizadas 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 característica primero se deshabilitó y luego se eliminó de la mayoría de los navegadores también debido a la adopción anunciada de HTTP/2.
HTTP/2 amplió el uso de conexiones persistentes al multiplexar muchas solicitudes/respuestas simultáneas a través de una única conexión TCP/IP.
HTTP/3 no utiliza conexiones TCP/IP sino QUIC + UDP (ver también: descripción técnica).
"Content-Length: number"no estaba presente en los encabezados HTTP y el cliente suponía que cuando el servidor cerró la conexión, el contenido había sido enteramente 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 o algo más).HTTP proporciona múltiples esquemas de autenticación, como la autenticación de acceso básico y la autenticación de acceso implícito , que funcionan mediante 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 un cliente y por un cliente para proporcionar información de autenticación. [1]
Los mecanismos de autenticación descritos anteriormente pertenecen al protocolo HTTP y son administrados por el software HTTP del cliente y del servidor (si está configurado para requerir autenticación antes de permitir el acceso del cliente a uno o más recursos web), y no por las aplicaciones web que utilizan una sesión de aplicación web.
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 dominio, si está presente, se combina con el URI raíz canónico para formar el componente de espacio de protección del desafío. De hecho, esto permite que el servidor defina ámbitos de autenticación separados bajo un URI raíz. [1]
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 múltiples solicitudes.
Algunas aplicaciones web necesitan gestionar las sesiones de los usuarios, por lo que implementan estados o sesiones del lado del servidor , utilizando, por ejemplo, cookies HTTP [45] 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 mediante el inicio de sesión de la aplicación web. Para detener la sesión de un usuario, el usuario debe solicitar una operación de cierre de sesión . Este tipo de operaciones no utilizan autenticación HTTP sino una autenticación de aplicación web administrada personalizada.
Los mensajes de solicitud son enviados por un cliente a un servidor de destino. [nota 4]
Un cliente envía mensajes de solicitud al servidor, que constan de: [46]
OBTENER /images/logo.png HTTP / 1.1Anfitrión: www.ejemplo.comAceptar-Idioma: en
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. [47]
HTTP define métodos (a veces denominados verbos , pero en ninguna parte de la especificación menciona el 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 generados 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 [48] definió los métodos GET, HEAD y POST, y la especificación HTTP/1.1 [49] agregó cinco métodos nuevos: PUT, DELETE, CONNECT, OPTIONS y TRACE. 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 intermedio, se tratará como un método inseguro y no idempotente . No hay límite para la cantidad de métodos que se pueden definir, lo que permite especificar métodos futuros sin 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. [50] [51] Esto contrasta con los nombres de campos de encabezado HTTP que no distinguen entre mayúsculas y minúsculas. [52]
Content-Length).Todos los servidores web 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. [51]
Un método de solicitud es seguro si una solicitud con ese método no tiene ningún efecto previsto en el servidor. Los métodos GET, HEAD, OPTIONS y TRACE se definen como seguros. En otras palabras, los métodos seguros están pensados para 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 publicitaria , 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. Podrán modificar el estado del servidor o tener otros efectos como el envío de un correo electrónico . Por lo tanto, estos métodos no suelen ser utilizados por robots o rastreadores web conformes; algunos que no se ajustan tienden a hacer solicitudes sin tener en cuenta el contexto o las consecuencias.
A pesar de la seguridad prescrita para las solicitudes GET, en la práctica su manejo por parte del servidor no está técnicamente limitado de ningún modo. 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 recupera arbitrariamente, incluso usando GET, simplemente eliminaría el artículo. [59] Un sitio web correctamente codificado requeriría un método DELETE o POST para esta acción, que los robots no maliciosos no realizarían.
Un ejemplo de esto ocurrió en la práctica durante la versión beta de corta duración de Google Web Accelerator , que precargaba direcciones URL arbitrarias en la página que un usuario estaba viendo, lo que provocaba que los registros se alteraran o eliminaran automáticamente en masa . La versión beta fue suspendida sólo unas semanas después de su primer lanzamiento, tras críticas generalizadas. [60] [59]
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 no pretenden tener ningún efecto en el servidor; Mientras tanto, los métodos PUT y DELETE son idempotentes ya que se ignorarán solicitudes idénticas sucesivas. Un sitio web podría, por ejemplo, configurar un punto final PUT para modificar la dirección de correo electrónico registrada de un usuario. Si este punto final está configurado correctamente, cualquier solicitud que solicite cambiar la dirección de correo electrónico de un usuario a la misma dirección de correo electrónico que ya está registrada (por ejemplo, solicitudes duplicadas después de una solicitud exitosa) no tendrá ningún efecto. De manera similar, una solicitud para ELIMINAR a un determinado usuario no tendrá ningún 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 puede ocurrir accidentalmente. Un usuario podría, por ejemplo, enviar sin darse cuenta varias solicitudes POST haciendo clic nuevamente en un botón si no recibió información 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 impone si un método es idempotente o no. Es perfectamente posible escribir una aplicación web en la que (por ejemplo) una inserción de base de datos u otra acción no idempotente se active mediante una solicitud GET u otra. Sin embargo, hacerlo en contra de las recomendaciones puede tener consecuencias indeseables si un agente de usuario asume que repetir la misma solicitud es seguro cuando no lo es.
Un método de solicitud se puede almacenar en caché si las respuestas a las solicitudes con ese método pueden almacenarse para su reutilización futura. 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é.
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). Proporcionan información sobre el cliente, sobre el recurso de destino o sobre el manejo esperado de la solicitud.
Un servidor envía un mensaje de respuesta a un cliente como respuesta a su mensaje de solicitud anterior. [nota 4]
Un servidor envía mensajes de respuesta al cliente, que constan de: [46]
HTTP / 1.1 200 OKTipo de contenido: texto/htmlEn 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 textual de motivo (como "No encontrado"). El código de estado de respuesta es un código entero de tres dígitos que representa el resultado del intento del servidor de comprender y satisfacer la solicitud correspondiente del cliente. La forma en que el cliente maneja la respuesta depende principalmente del código de estado y, en segundo lugar, de los demás campos del encabezado de la 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 sólo recomendaciones y pueden sustituirse por "equivalentes locales" a discreción del desarrollador web . Si el código de estado indicaba un problema, el agente de usuario podría mostrar la frase del 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 no ser prudente 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)2XX(exitoso)3XX(redirección)4XX(error del cliente)5XX(Error del Servidor)Los campos del encabezado de respuesta permiten al servidor pasar información adicional más allá de la línea de estado, actuando como modificadores de respuesta. Proporcionan información sobre el servidor o sobre el acceso adicional al recurso de destino o recursos relacionados.
Cada campo de encabezado de respuesta tiene un significado definido que puede refinarse aún más mediante la semántica del método de solicitud o el código de estado de respuesta.
A continuación se muestra un ejemplo de transacción HTTP entre un cliente HTTP/1.1 y un servidor HTTP/1.1 que se ejecuta en www.example.com , puerto 80. [nota 5] [nota 6]
GET / HTTP / 1.1 Host : www.example.com Agente de usuario : Mozilla/5.0 Aceptar : text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/* ;q=0.8 Idioma de aceptación : en-GB,en;q=0.5 Codificación de aceptación : gzip, deflate, br Conexión : keep-aliveUna solicitud de cliente (que en este caso consta de la línea de solicitud y algunos encabezados que se pueden reducir a solo el "Host: hostname"encabezado) va seguida de una línea en blanco, de modo que la solicitud termina con un doble final de línea, cada uno en forma de retorno de carro seguido de un avance de línea . El "Host: hostname"valor del encabezado distingue entre varios nombres DNS que comparten una única dirección IP , lo que permite el alojamiento virtual basado en nombres . Aunque es opcional en HTTP/1.0, es obligatorio en HTTP/1.1. (Una "/" (barra oblicua) normalmente recuperará un archivo /index.html si lo hay).
HTTP / 1.1 200 OK Fecha : lunes 23 de mayo de 2005 22:38:34 GMT Tipo de contenido : texto/html; charset=UTF-8 Longitud del contenido : 155 Última modificación : miércoles, 8 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> </body> </html> _ _ _ _ _ _El campo de encabezado ETag (etiqueta de entidad) se utiliza 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 tener solo ciertas partes [61] de un recurso enviado por el servidor, 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 de finalizar la transferencia de esta respuesta. [21]
La mayoría de las líneas de encabezado son opcionales, pero algunas son obligatorias. Cuando "Content-Length: number"falta el encabezado en una respuesta con un cuerpo de entidad, esto 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 omitían 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 continuaba hasta que el servidor cerraba el socket.
A se puede utilizar para informar al cliente que la parte de la entidad del cuerpo de los datos transmitidos está comprimida mediante el algoritmo gzip."Content-Encoding: gzip"
La forma más popular de establecer una conexión HTTP cifrada es HTTPS . [62] También existen otros dos métodos para establecer una conexión HTTP cifrada: el 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, la compatibilidad del navegador con estos dos es casi inexistente. [63] [64] [65]
Esto reduce la barrera para implementar TLS 1.3, una importante mejora de seguridad con respecto a TLS 1.2.
Un error común es utilizar GET para una acción que actualiza un recurso. [...] Este problema salió a la luz pública de Rails en 2005, cuando se lanzó Google Web Accelerator.
