Wikibrief

Protocolo de Transferencia de Hipertexto

Editar artículo
Esta es la última revisión aceptada, revisada el 18 de octubre de 2021.

Protocolo de Transferencia de Hipertexto
HTTP logo.svg
Estándar internacional RFC   1945 HTTP / 1.0 (1996)

RFC   2068 HTTP / 1.1 (1997) RFC   2616 HTTP / 1.1 (1999) RFC   7230 HTTP / 1.1: Sintaxis y enrutamiento de mensajes (2014) RFC   7231 HTTP / 1.1: Semántica y contenido (2014) RFC   7232 HTTP / 1.1: Solicitudes condicionales ( 2014) RFC   7233 HTTP / 1.1: Solicitudes de rango (2014) RFC   7234 HTTP / 1.1: Almacenamiento en caché (2014) RFC   7235 HTTP / 1.1: Autenticación (2014) RFC   7540 HTTP / 2 (2015) RFC   7541 HTTP / 2: Compresión de encabezado HPACK (2015) RFC   8164 HTTP / 2: Seguridad oportunista para HTTP / 2 (2017) RFC   8336 HTTP / 2: El marco ORIGIN HTTP / 2 (2018) RFC   8441 HTTP / 2: Bootstrapping WebSockets con HTTP / 2 (2018)

RFC   8740 HTTP / 2: uso de TLS 1.3 con HTTP / 2 (2020)
Desarrollado por inicialmente CERN ; IETF, W3C
Introducido 1991 ; Hace 30 años ( 1991)
HTTP
Métodos de solicitud
Campos de encabezado
Códigos de estado de respuesta
Métodos de control de acceso de seguridad
Vulnerabilidades de seguridad
  • v
  • t
  • mi
Conjunto de protocolos de internet
Capa de aplicación
Capa de transporte
Capa de internet
Capa de enlace
  • más...
  • v
  • t
  • mi

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 distribuidos, colaborativos e hipermedia. 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 en un navegador web.

El desarrollo de HTTP fue iniciado por Tim Berners-Lee en el CERN en 1989 y resumido en un documento simple que describe el comportamiento de un cliente y un servidor usando la primera versión del protocolo HTTP que se llamó 0.9.

El desarrollo de las primeras solicitudes HTTP para comentarios (RFC) comenzó unos años más tarde y fue 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 documentó por primera vez (como versión 1.0) en 1996. Evolucionó (como versión 1.1) en 1997.

HTTP / 2 es una expresión más eficiente de la semántica de HTTP "en el cable", se publicó en 2015 y es utilizado por el 45% de los sitios web; ahora es compatible con prácticamente todos los navegadores web y los principales servidores web a través de Transport Layer Security (TLS) utilizando una extensión Application-Layer Protocol Negotiation (ALPN) donde se requiere TLS 1.2 o más reciente.

HTTP / 3 es el sucesor propuesto de HTTP / 2, y dos tercios de los usuarios de navegadores web (tanto en computadoras de escritorio como en dispositivos móviles) ya pueden usar HTTP / 3, en el 20% de los sitios web que ya lo admiten; utiliza QUIC en lugar de TCP para el protocolo de transporte subyacente. Al igual que HTTP / 2, no hace obsoletas las versiones principales anteriores del protocolo. Primero se agregó soporte para HTTP / 3 a Cloudflare y Google Chrome, y también está habilitado en Firefox.

Contenido
  • 1 Descripción técnica
  • 2 Historia
  • 3 sesión HTTP
    • 3.1 Conexiones persistentes
    • 3.2 Optimizaciones de recuperación de contenido
    • 3.3 estado de la sesión HTTP
  • 4 autenticación HTTP
    • 4.1 Reinos de autenticación
  • 5 Solicitar mensajes
    • 5.1 Solicitud de sintaxis
    • 5.2 Métodos de solicitud
      • 5.2.1 Métodos seguros
      • 5.2.2 Métodos idempotentes
      • 5.2.3 Métodos que se pueden almacenar en caché
    • 5.3 Campos de encabezado de solicitud
  • 6 Mensajes de respuesta
    • 6.1 Sintaxis de respuesta
    • 6.2 Códigos de estado de respuesta
    • 6.3 Campos de encabezado de respuesta
  • 7 conexiones cifradas
  • 8 Sesión de ejemplo
    • 8.1 Solicitud del cliente
    • 8.2 Respuesta del servidor
  • 9 Protocolos similares
  • 10 Véase también
  • 11 referencias
  • 12 Enlaces externos

Resumen técnico

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, 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 a salto, mientras que otros encabezados HTTP se administran de un extremo a otro. 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 dentro del marco del conjunto de protocolos de Internet. Su definición presupone 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 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, en cambio, puede reutilizar una conexión para realizar múltiples solicitudes de recursos (es decir, de páginas HTML, marcos, imágenes, scripts, hojas de estilo, etc.).

Por lo tanto, las comunicaciones HTTP / 1.1 experimentan menos latencia ya que el establecimiento de conexiones TCP presenta una sobrecarga considerable, especialmente en condiciones de alto tráfico.

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

  • utilizar una representación binaria comprimida de metadatos (encabezados HTTP) en lugar de uno textual, de modo que los encabezados requieran mucho menos espacio;
  • utilizar una única conexión TCP / IP (normalmente cifrada ) por dominio de servidor al que se accede en lugar de 2.. 8 conexiones TCP / IP;
  • utilizar uno o más flujos bidireccionales por conexión TCP / IP en los que las solicitudes y respuestas HTTP se desglosan y transmiten en pequeños paquetes para resolver el problema del HOLB ( bloqueo de cabecera de línea ; NOTA: en la práctica, estos flujos se utilizan como múltiples TCP / Subconexiones IP para multiplexar solicitudes / respuestas simultáneas, lo que reduce considerablemente el número de conexiones TCP / IP reales en el lado del servidor, de 2..8 por cliente a 1, y permite atender a muchos más clientes a la vez);
  • para agregar una capacidad de inserción para permitir que la aplicación del servidor envíe datos a los clientes siempre que haya nuevos datos disponibles (sin obligar a los clientes a solicitar periódicamente nuevos datos al servidor mediante métodos de sondeo ).

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

HTTP / 3 es una revisión de HTTP / 2 anterior para poder utilizar los protocolos de transporte UDP + QUIC en lugar de las conexiones TCP / IP y así superar el problema de la congestión de la conexión TCP / IP que puede bloquear o ralentizar el flujo de datos de todos sus arroyos.

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. El primer servidor web se puso en marcha en 1990. El protocolo utilizado tenía un solo método, a saber, GET, que solicitaba una página de un servidor. La respuesta del servidor siempre fue una página HTML.

La primera versión documentada de HTTP se escribió en 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 convirtió en más eficiente agregando métodos adicionales y campos de encabezado. RFC   1945 introdujo y reconoció oficialmente la versión 1.0 de HTTP en 1996.

El HTTP WG planeaba publicar nuevos estándares en diciembre de 1995 y el soporte para el estándar HTTP / 1.1 basado en el RFC   2068 (llamado HTTP-NG) en desarrollo fue rápidamente adoptado por los principales desarrolladores de navegadores a principios de 1996. Adopción por parte del usuario final de los nuevos navegadores fue rápido. 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. 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

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

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

  • es claramente obsoleto porque es tan simple que nadie se molestó ni siquiera en escribir un documento RFC (solo existe el documento original);
  • no tiene encabezados HTTP y también carece de muchas otras características que hoy en día son realmente necesarias por razones mínimas de seguridad;
  • no se ha utilizado realmente desde 1999..2000 (debido a HTTP / 1.0 y HTTP / 1.1);
  • parece que solo lo utilizan aleatoriamente algunos hardware de red muy antiguos, es decir, enrutadores, etc.

En 2021, el soporte HTTP / 0.9 todavía está presente en muchos servidores web y navegadores (solo para respuestas del servidor), por lo que no está claro cuánto tiempo llevará esta eliminación, tal vez se complete primero en agentes de usuario (navegadores, etc.) y luego en servidores web.

Año Versión
1991 HTTP / 0.9
1996 HTTP / 1.0
1997 HTTP / 1.1
2015 HTTP / 2
2020 (borrador) HTTP / 3

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

Conexiones persistentes

Artículo principal: conexión persistente HTTP

En HTTP / 0.9 el protocolo TCP / IP de conexión siempre está cerrada después de la respuesta del servidor ha sido enviado.

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: desde finales de 1996, algunos desarrolladores de navegadores y servidores HTTP / 1.0 populares (especialmente aquellos que también habían planeado soporte para HTTP / 1.1), comenzaron a implementar (como una extensión no oficial) una especie de mecanismo de mantener vivo (mediante el uso de nuevos encabezados HTTP) para mantener la conexión TCP / IP abierta para más de un par de solicitud / respuesta y así acelerar el intercambio de múltiples solicitudes / respuestas.

En HTTP / 1.1 se introdujo oficialmente un mecanismo de mantenimiento de vida para que una conexión pudiera reutilizarse para más de una solicitud / respuesta. 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.

HTTP / 1.1 agregó también canalización HTTP para reducir aún más el tiempo de retraso cuando se usan conexiones persistentes al permitir que los clientes envíen múltiples solicitudes antes de esperar cada respuesta. Esta optimización nunca se consideró realmente segura porque algunos servidores web y muchos servidores proxy, servidores proxy especialmente transparentes colocados en Internet / Intranets entre clientes y servidores, no manejaban adecuadamente las solicitudes canalizadas (solo atendían la primera solicitud descartando las otras o cerraban la conexión porque vieron más datos después de la primera solicitud, etc.). Además de esto, solo las solicitudes GET y HEAD 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 se deshabilitó primero y luego se eliminó de la mayoría de los navegadores también debido a la adopción anunciada de HTTP / 2.

HTTP / 2 extendió el uso de conexiones persistentes por multiplexación muchas solicitudes simultáneas / respuestas a través de una sola conexión TCP / IP.

HTTP / 3 no utiliza conexiones TCP / IP sino UDP + QUIC para evitar el problema de la congestión TCP / IP de una conexión.

Optimizaciones de recuperación de contenido

En HTTP / 0.9, un recurso solicitado siempre se envió por completo.

HTTP / 1.0 agregó encabezados para administrar los recursos almacenados en caché por el cliente para permitir solicitudes GET condicionales ; en la práctica, un servidor tiene que devolver todo el contenido del recurso solicitado solo si el cliente no conoce su última hora de modificación o si ha cambiado desde la última respuesta completa a la solicitud GET.

HTTP / 1.0 agregó el encabezado "Codificación de contenido" para especificar si el contenido devuelto de un recurso estaba comprimido o no.

En HTTP / 1.0, si la longitud total del contenido de un recurso no se conocía de antemano (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 en su totalidad. Este mecanismo no podía distinguir entre una transferencia de recursos completada con éxito y una interrumpida (debido a un error de servidor / red u otra cosa).

HTTP / 1.1 agregó nuevos encabezados para administrar mejor la recuperación condicional de recursos almacenados en caché.

HTTP / 1.1 introdujo la codificación de transferencia fragmentada para permitir que el contenido se transmita en fragmentos para enviarlo de manera confiable incluso cuando el servidor no conoce de antemano su longitud (es decir, porque se genera dinámicamente, etc.).

HTTP / 1.1 agregó también servicio de rango de bytes, donde un cliente puede solicitar solo una o más porciones (rangos de bytes) de un recurso (es decir, la primera parte, una parte en el medio o al final de todo el contenido, etc.) y el servidor generalmente envía solo las partes solicitadas. Esto es útil para reanudar una descarga interrumpida (cuando un archivo es realmente grande), cuando un navegador solo debe mostrar o agregar dinámicamente una parte de un contenido a la parte ya visible (es decir, solo el primero o los siguientes n comentarios de una página web) para ahorrar tiempo, ancho de banda y recursos del sistema, etc.

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

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.

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.

Solicitar mensajes

Solicitar sintaxis

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

  • una línea de solicitud, que consta del método de solicitud que distingue entre mayúsculas y minúsculas, un espacio, el destino de la solicitud, otro espacio, la versión del protocolo, un retorno de carro y un salto de línea, por ejemplo:
GET /images/logo.png HTTP/1.1
  • cero o más campos de encabezado de solicitud (al menos 1 o más encabezados en el caso de HTTP / 1.1), cada uno formado por el nombre del campo que no distingue entre mayúsculas y minúsculas, dos puntos, un espacio en blanco inicial opcional, el valor del campo, un espacio en blanco final opcional y un final con un retorno de carro y un salto de línea, por ejemplo:
Host: www.example.com Accept-Language: en
  • una línea vacía, que consta de un retorno de carro y un salto de línea;
  • un cuerpo de mensaje opcional.

En el protocolo HTTP / 1.1, todos los campos de encabezado excepto Host: hostnameson opcionales.

Los servidores aceptan una línea de solicitud que contiene solo el nombre de la ruta para mantener la compatibilidad con los clientes HTTP antes de la especificación HTTP / 1.0 en RFC   1945.

Métodos de solicitud

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 definió los métodos GET, HEAD y POST, y la especificación HTTP / 1.1 agregó cinco métodos nuevos: PUT, DELETE, CONNECT, OPTIONS y TRACE. 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. Esto contrasta con los nombres de campo de encabezado HTTP que no distinguen entre mayúsculas y minúsculas.

OBTENER
El método GET solicita que el recurso de destino transfiera una representación de su estado. Las solicitudes GET solo deben recuperar datos y no deben tener ningún otro efecto. (Esto también es cierto para algunos otros métodos HTTP). 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". Consulte los métodos seguros a continuación.
CABEZA
El método HEAD solicita que el recurso de destino transfiera una representación de su estado, como para una solicitud GET, pero sin los datos de representación incluidos en el cuerpo de la respuesta. Esto es útil para recuperar los metadatos de representación en el encabezado de respuesta, sin tener que transferir la representación completa.
CORREO
El método POST solicita que el recurso de destino procese la representación incluida en la solicitud de acuerdo con la semántica del recurso de destino. Por ejemplo, se utiliza para publicar un mensaje en un foro de Internet, suscribirse a una lista de correo o completar una transacción de compra en línea.
PONER
El método PUT solicita que el recurso de destino cree o actualice su estado con el estado definido por la representación incluida en la solicitud.
ELIMINAR
El método DELETE solicita que el recurso de destino elimine su estado.
CONECTAR
El método CONNECT solicita que el intermediario establezca un túnel TCP / IP al servidor de origen identificado por el destino de la solicitud. A menudo se usa para asegurar conexiones a través de uno o más proxies HTTP con TLS. Consulte el método HTTP CONNECT.
OPCIONES
El método OPTIONS solicita que el recurso de destino transfiera los métodos HTTP que admite. Esto se puede usar para verificar la funcionalidad de un servidor web solicitando '*' en lugar de un recurso específico.
RASTRO
El método TRACE solicita que el recurso de destino transfiera la solicitud recibida en el cuerpo de respuesta. De esa manera, un cliente puede ver qué cambios (si los hay) o adiciones han realizado los intermediarios.
PARCHE
El método PATCH solicita que el recurso de destino modifique su estado de acuerdo con la actualización parcial definida en la representación incluida en la solicitud.

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.

Propiedades de los métodos de solicitud
Método de solicitud RFC La solicitud tiene cuerpo de carga útil La respuesta tiene cuerpo de carga útil A salvo Idempotente Almacenable en caché
OBTENER RFC   7231 Opcional sí sí sí sí
CABEZA RFC   7231 Opcional No sí sí sí
CORREO RFC   7231 sí sí No No sí
PONER RFC   7231 sí sí No sí No
ELIMINAR RFC   7231 Opcional sí No sí No
CONECTAR RFC   7231 Opcional sí No No No
OPCIONES RFC   7231 Opcional sí sí sí No
RASTRO RFC   7231 No sí sí sí No
PARCHE RFC   5789 sí sí No No No

Métodos seguros

Un método de solicitud es seguro si una solicitud con ese método no tiene 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 la solicitud a un archivo de registro o cargar una cuenta de publicidad, ya que el cliente no los solicita, por definición.

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, 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.

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.

Métodos idempotentes

Ver también: Idempotente § Significado de la informática

Un método de solicitud es idempotente si varias solicitudes idénticas con ese método tienen el mismo efecto previsto que una sola solicitud de este tipo. Los métodos PUT y DELETE y los métodos seguros se definen como idempotentes.

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 un correo electrónico. 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.

Métodos que se pueden almacenar en caché

Ver también: caché web

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é.

Solicitar campos de encabezado

Ver también: Lista de campos de encabezado HTTP § Campos de solicitud

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.

Mensajes de respuesta

Sintaxis de respuesta

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

HTTP/1.1 200 OK
  • cero o más campos de encabezado de respuesta, cada uno de los cuales consta del nombre del campo que no distingue entre mayúsculas y minúsculas, dos puntos, un espacio en blanco inicial opcional, el valor del campo, un espacio en blanco final opcional y termina con un retorno de carro y un avance de línea, por ejemplo:
Content-Type: text/html
  • una línea vacía, que consta de un retorno de carro y un salto de línea;
  • un cuerpo de mensaje opcional.

Códigos de estado de respuesta

Ver 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"). 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 de encabezado de respuesta. Es posible que los clientes no comprendan todos los códigos de estado registrados, pero deben comprender su clase (dada por el primer dígito del código de estado) y tratar un código de estado no reconocido como equivalente al código de estado x00 de esa clase.

Las frases de motivo estándar son solo recomendaciones y 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 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 ser imprudente ya que el estándar especifica explícitamente que los códigos de estado son legibles por máquina y las frases de motivo son legibles por humanos.

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

1XX (informativo)
Se recibió la solicitud, proceso continuo.
2XX (exitoso)
La solicitud fue recibida, comprendida y aceptada con éxito.
3XX (redirección)
Es necesario realizar más acciones para completar la solicitud.
4XX (error del cliente)
La solicitud contiene una sintaxis incorrecta o no se puede cumplir.
5XX (Error del Servidor)
El servidor no cumplió con una solicitud aparentemente válida.

Campos de encabezado de respuesta

Ver también: Lista de campos de encabezado HTTP § Campos de respuesta

Los campos de 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 se puede refinar aún más mediante la semántica del método de solicitud o el código de estado de respuesta.

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.

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 User-Agent: Mozilla/5.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-GB,en;q=0.5 Accept-Encoding: gzip, deflate, br Connection: keep-alive

Una solicitud de cliente (que en este caso consiste en la línea de solicitud y algunos encabezados que se pueden reducir solo al "Host: hostname"encabezado) va seguida de una línea en blanco, de modo que la solicitud termina con un final de línea doble, cada uno en forma de retorno de carro seguido de un salto de línea. El "Host: hostname"valor del encabezado distingue entre varios nombres DNS que comparten una sola 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 Date: Mon, 23 May 2005 22:38:34 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 155 Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) ETag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Connection: close lt;htmlgt; lt;headgt; lt;titlegt;An Example Pagelt;/titlegt; lt;/headgt; lt;bodygt; lt;pgt;Hello World, this is a very simple HTML document.lt;/pgt; lt;/bodygt; lt;/htmlgt;

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 que el servidor envíe solo ciertas partes de un recurso, lo que se denomina servicio de bytes. Cuando "Connection: close"se envía, significa que el servidor web cerrará la conexión TCP inmediatamente después del final de la transferencia de esta respuesta.

La mayoría de las líneas de encabezado son opcionales, pero algunas son obligatorias. Cuando "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 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 la longitud de la entidad del cuerpo no se conocía al comienzo de la respuesta y, por lo tanto, la transferencia de datos al cliente continuó hasta que el servidor cerró el socket.

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

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.
  • El protocolo Gemini es un protocolo inspirado en Gopher que exige funciones relacionadas con la privacidad.

Ver también

HTTP
Métodos de solicitud
Campos de encabezado
Códigos de estado de respuesta
Métodos de control de acceso de seguridad
Vulnerabilidades de seguridad
  • v
  • t
  • mi

Referencias

enlaces externos

Contactos: mail@wikibrief.org
El contenido está disponible bajo la licencia CC BY-SA 3.0 (a menos que se indique lo contrario).