Protocolo de transferencia de hipertexto

Protocolo de transferencia de hipertexto
Familia	Familia de protocolos de Internet
Función	Transferencia de hipertexto
Última versión	3.0 (2018)
Puertos	80/TCP
Ubicación en la pila de protocolos
Aplicación HTTP Transporte TCP Red IP
Estándares
Original HTTP (HTTP/0.9, 1991) RFC 1945 (HTTP/1.0, 1996) RFC 2616 (HTTP/1.1, 1999) RFC 2774 (HTTP/1.2[cita requerida], 2000) RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235 (revisión de HTTP/1.1, 2014) RFC 7540 (HTTP/2, 2015) Hypertext Transfer Protocol Version 3 (HTTP/3, 2018) (Borrador de Internet)

El protocolo de transferencia de hipertexto (en inglés: Hypertext Transfer Protocol, abreviado HTTP) es el protocolo de comunicación que permite las transferencias de información a través de archivos (XML, HTML…) en la World Wide Web. Fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force, colaboración que culminó en 1999 con la publicación de una serie de RFC, siendo el más importante de ellos el RFC 2616 que especifica la versión 1.1. HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse.

HTTP es un protocolo sin estado, por lo que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de sesión, y también permite rastrear usuarios, ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

Descripción

Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. El cliente (se le suele llamar "agente de usuario", del inglés user agent) realiza una petición enviando un mensaje, con cierto formato al servidor. El servidor (al que es común llamarle servidor web) le envía un mensaje de respuesta. Ejemplos de cliente son los navegadores web y las arañas web (también conocidas por su término inglés, webcrawlers).

Mensajes

Los mensajes HTTP son en texto plano, lo que lo hace más legible y fácil de depurar. Sin embargo, esto tiene el inconveniente de hacer los mensajes más largos. Los mensajes tienen la siguiente estructura:

• Línea inicial (termina con retorno de carro y un salto de línea) con
  • Para las peticiones: la acción requerida por el servidor (método de petición) seguido de la URL del recurso y la versión de HTTP que soporta el cliente.
  • Para respuestas: la versión del HTTP usado seguido del código de respuesta (que indica qué ha pasado con la petición seguido de la URL del recurso) y de la frase asociada a dicho retorno.
• Las cabeceras del mensaje que terminan con una línea en blanco. Son metadatos. Estas cabeceras le dan gran flexibilidad al protocolo.
• Cuerpo del mensaje. Es opcional. Su presencia depende de la línea anterior del mensaje y del tipo de recurso al que hace referencia la URL. Típicamente tiene los datos que se intercambian cliente y servidor. Por ejemplo, para una petición podría contener ciertos datos que se quieren enviar al servidor para que los procese. Para una respuesta podría incluir los datos que el cliente ha solicitado.

Métodos de petición

Un pedido HTTP usando telnet. La petición (request), cabeceras de respuesta (response headers) y el cuerpo de la respuesta (response body) están resaltados.

HTTP define una serie predefinida de métodos de petición (algunas veces denominados "verbos", aunque este término no está presente en las especificaciones) para indicar la acción que se desea realizar sobre el recurso identificado. Que este recurso sea preexistente (datos ya almacenados) o se genere de forma dinámica depende de la implementación del servidor. A menudo, el recurso corresponde a un archivo o a la salida de un ejecutable que reside en el servidor.

La especificación de HTTP/1.0 define los métodos GET, HEAD y POST y enumera los métodos PUT, DELETE, LINK Y UNLINK en una sección de métodos adicionales. Sin embargo, la especificación HTTP/1.1 define formalmente y añade cinco métodos nuevos: PUT, DELETE, CONNECT, OPTIONS y TRACE. Cualquier cliente puede utilizar cualquier método y el servidor se puede configurar para dar soporte a cualquier combinación de métodos. En caso de que un método sea desconocido para un intermediario, lo tratará como un método inseguro y no idempotente. No hay límite para el número de métodos que se pueden definir, lo que permite que se puedan especificar nuevos métodos sin afectar la infraestructura anterior. Por ejemplo, WebDAV definió siete métodos nuevos y el RFC 5789 especificó el método PATCH.

Los nombres de los métodos son sensibles a mayúsculas. Esto contrasta con los nombres de los campos de las cabeceras HTTP, que no son sensibles a mayúsculas.

Definiciones

1. Un método de petición es seguro si una petición con ese método no tiene un efecto intencional en el servidor. En otras palabras, un método es seguro si es de solo lectura. Sin embargo, un método seguro puede tener efectos secundarios que el cliente no puede ver, como añadir información de la petición a un archivo de registro o realizar un cobro a una cuenta de publicidad.
2. Un método es idempotente si múltiples peticiones con ese método tienen el mismo efecto que una sola petición. Los métodos seguros son trivialmente idempotentes, ya que no deberían tener efecto alguno en el servidor.
3. Un método es cacheable si se pueden almacenar las respuestas para su futura reutilización.

Métodos estándar

Todos los servidores web de propósito general deben implementar al menos los métodos GET y HEAD, mientras que el resto de métodos son opcionales.​

Propiedades de los métodos de petición

Método	RFC	La petición tiene carga útil	La respuesta tiene carga útil	Seguro	Idempotente	Cacheable
GET	RFC 9110	Opcional	Sí	Sí	Sí	Sí
HEAD	RFC 9110	Opcional	No	Sí	Sí	Sí
POST	RFC 9110	Sí	Sí	No	No	Sí
PUT	RFC 9110	Sí	Sí	No	Sí	No
DELETE	RFC 9110	Opcional	Sí	No	Sí	No
CONNECT	RFC 9110	Opcional	Sí	No	No	No
OPTIONS	RFC 9110	Opcional	Sí	Sí	Sí	No
TRACE	RFC 9110	No	Sí	Sí	Sí	No
PATCH	RFC 5789	Sí	Sí	No	No	No

GET

El método GET solicita que el recurso de destino transfiera una representación de su estado. Las solicitudes que usan GET solo deben recuperar datos y no deben tener ningún otro efecto. (Esto también es cierto para algunos otros métodos HTTP.)​ Para recuperar recursos sin realizar cambios, es preferible GET sobre POST, ya que se puede acceder a esos recursos a través de una URL. Esto permite añadir la URL a marcadores y compartirla y hace que las respuestas GET se puedan almacenar en caché, lo que ahorra ancho de banda. El W3C ha publicado principios orientadores sobre esta distinción, indicando: «El diseño de aplicaciones web debe estar informado de los principios anteriores, pero también de las limitaciones relevantes».​

HEAD

El método HEAD solicita que el recurso de destino transfiera una representación de su estado, al igual que el método GET, pero sin los datos de representación contenidos en el cuerpo de la respuesta. Esto es útil para poder recuperar los metadatos de las cabeceras de la respuesta, sin tener que transportar el contenido completo. Se puede usar, por ejemplo, para comprobar si una página está disponible a través del código de estado o para obtener rápidamente el tamaño de un archivo (Content-Length).​

POST

El método POST solicita que el recurso de destino procese la representación contenida en la petición de acuerdo con la semántica del propio recurso. A nivel semántico está orientado a crear un nuevo recurso, cuya naturaleza vendrá especificada por la cabecera Content-Type. Se puede usar, por ejemplo, para publicar un mensaje en un foro de Internet, suscribirse a una lista de correo o completar una compra en línea.​

PUT

Envía datos al servidor, pero a diferencia del método POST la URI de la línea de petición no hace referencia al recurso que los procesará, sino que identifica a los propios datos. Otra diferencia con POST es semántica (ver REST): mientras que POST está orientado a la creación de nuevos contenidos, PUT está más orientado a la actualización de los mismos (aunque también podría crearlos).​

DELETE

Borra el recurso especificado.​

TRACE

Solicita al servidor que introduzca en la respuesta todos los datos que reciba en el mensaje de petición. Se utiliza con fines de depuración y diagnóstico ya que el cliente puede ver lo que llega al servidor y de esta forma ver todo lo que añaden al mensaje los servidores intermedios.​

OPTIONS

Devuelve los métodos HTTP que el servidor soporta para un URL específico. Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante petición en lugar de un recurso específico.​

CONNECT

Se utiliza para saber si se tiene acceso a un host, no necesariamente la petición llega al servidor, este método se utiliza principalmente para saber si un proxy nos da acceso a un host bajo condiciones especiales, como por ejemplo "corrientes" de datos bidireccionales cifradas (como lo requiere SSL/TLS).​

PATCH

Su función es la misma que PUT, el cual sobrescribe completamente un recurso. Se utiliza para actualizar, de manera parcial una o varias partes. Está orientado también para el uso con proxy.​

Métodos de WebDAV

WebDAV añade los métodos siguientes:

COPY

Copia un recurso de una URI a otra.​

MOVE

Mueve un recurso de una URI a otra.​

LOCK

Bloquea un recurso.​

UNLOCK

Desbloquea un recurso.​

MKCOL

Crea una nueva colección de recursos en la ubicación especificada en el Request-URI.​

PROPFIND

Obtiene las propiedades de un recurso.​

PROPPATCH

Modifica las propiedades de un recurso.​

Asimismo, el RFC 3253 (marzo de 2002) introduce múltiples métodos adicionales para gestionar el control de versiones, como REPORT, MKACTIVITY, CHECKOUT y MERGE.

Métodos de SIP

El protocolo de iniciación de sesión (SIP) introduce los eventos SUBSCRIBE y NOTIFY para la notificación de eventos, especificados en el RFC 6665 (julio de 2012).

Códigos de respuesta

El código de respuesta o retorno es un número que indica que ha pasado con la petición. El resto del contenido de la respuesta dependerá del valor de este código. El sistema es flexible, y de hecho la lista de códigos ha ido aumentando para así adaptarse a los cambios e identificar nuevas situaciones.

Cada código tiene un significado concreto. Sin embargo, el número de los códigos están elegidos de tal forma que según si pertenece a una centena u otra se pueda identificar el tipo de respuesta que ha dado el servidor:

Códigos con formato 1xx

Respuestas informativas. Indica que la petición ha sido recibida y se está procesando.

Códigos con formato 2xx

Respuestas correctas. Indica que la petición ha sido procesada correctamente.

Códigos con formato 3xx

Respuestas de redirección. Indica que el cliente necesita realizar más acciones para finalizar la petición.

Códigos con formato 4xx

Errores causados por el cliente. Indica que ha habido un error en el procesado de la petición a causa de que el cliente ha hecho algo mal.

Códigos con formato 5xx

Errores causados por el servidor. Indica que ha habido un error en el procesado de la petición a causa de un fallo en el servidor.

Cabeceras

Son los metadatos que se envían en las peticiones o respuesta HTTP para proporcionar información esencial sobre la transacción en curso. Cada cabecera es especificada por un nombre de cabecera seguido por dos puntos, un espacio en blanco y el valor de dicha cabecera seguida por un retorno de carro seguido por un salto de línea. Se usa una línea en blanco para indicar el final de las cabeceras. Si no hay cabeceras la línea en blanco debe permanecer.

Las cabeceras le dan gran flexibilidad al protocolo permitiendo añadir nuevas funcionalidades sin tener que cambiar la base. Por eso según han ido sucediendo las versiones de HTTP se han ido añadiendo más y más cabeceras permitidas.

Las cabeceras pueden tener metadatos que tienen que ser procesados por el cliente (ej. en respuesta a petición se puede indicar el tipo del contenido que contiene), por el servidor (ej. tipos de representaciones aceptables por el cliente del contenido que pide) o por los intermediarios (ej. como gestionar el cacheo por parte de los proxys)

Dependiendo del tipo de mensaje en el que puede ir una cabecera las podemos clasificar en cabeceras de petición, cabeceras de respuesta y cabeceras que pueden ir tanto en una petición como en una respuesta.

Podemos clasificar las cabeceras según su función. Por ejemplo:

• Cabeceras que indican las capacidades aceptadas por el que envía el mensaje: Accept (indica el MIME aceptado), Accept-Charset (indica el código de caracteres aceptado), Accept-Encoding (indica el método de compresión aceptado), Accept-Language (indica el idioma aceptado), User-Agent (para describir al cliente), Server (indica el tipo de servidor), Allow (métodos permitidos para el recurso)
• Cabeceras que describen el contenido: Content-Type (indica el MIME del contenido), Content-Length (longitud del mensaje), Content-Range, Content-Encoding, Content-Language, Content-Location.
• Cabeceras que hacen referencias a URIs: Location (indica donde está el contenido), Referer (Indica el origen de la petición).
• Cabeceras que permiten ahorrar transmisiones: Date (fecha de creación), If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, If-Range, Expires, Last-Modified, Cache-Control, Via, Pragma, Etag, Age, Retry-After.
• Cabeceras para control de cookies: Set-Cookie, Cookie
• Cabeceras para autentificación: Authorization, WW-Authenticate.
• Cabeceras para describir la comunicación: Host (indica máquina destino del mensaje), Connection (indica como establecer la conexión)
• Otras: Range (para descargar solo partes del recurso), Max-Forward (límite de cabeceras añadidas en TRACE).

Ejemplo de diálogo HTTP

Para obtener un recurso con el URL http://www.example.com/index.html

1. Se abre una conexión en el puerto 80 del host www.example.com. El puerto 80 es el puerto predefinido para HTTP. Si se quisiera utilizar el puerto XXXX, habría que codificarlo en la URL de la forma http://www.example.com:XXXX/index.html.
2. Se envía un mensaje en el estilo siguiente:

 GET /index.html HTTP/1.1
 Host: www.example.com
 Referer: www.google.com
 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
 Connection: keep-alive
 [Línea en blanco]

La respuesta del servidor está formada por encabezados seguidos del recurso solicitado, en el caso de una página web:

HTTP/1.1 200 OK
Date: Fri, 31 Dec 2003 23:59:59 GMT
Content-Type: text/html
Content-Length: 1221

<html lang="eo">
<head>
<meta charset="utf-8">
<title>Título del sitio</title>
</head>
<body>
<h1>Página principal de tuHost</h1>
(Contenido)
  .
  .
  .
</body>
</html>

Versiones

HTTP ha pasado por múltiples versiones del protocolo, muchas de las cuales son compatibles con las anteriores. El RFC 2145 describe el uso de los números de versión de HTTP. El cliente le dice al servidor al principio de la petición la versión que usa, y el servidor usa la misma o una anterior en su respuesta.

0.9 (lanzada en 1991)

Obsoleta. Soporta solo un comando, GET, y además no especifica el número de versión HTTP. No soporta cabeceras. Como esta versión no soporta POST, el cliente no puede enviarle mucha información al servidor.

HTTP/1.0 (mayo de 1996)

Esta es la primera revisión del protocolo que especifica su versión en las comunicaciones, y todavía se usa ampliamente, sobre todo en servidores proxy. Permite los métodos de petición GET, HEAD y POST.

HTTP/1.1 (junio de 1999)​​

Versión más usada actualmente;^{[cita requerida]} Las conexiones persistentes están activadas por defecto y funcionan bien con los proxies. También permite al cliente enviar múltiples peticiones a la vez por la misma conexión (pipelining) lo que hace posible eliminar el tiempo de Round-Trip delay por cada petición.

HTTP/1.2 (febrero de 2000)

Los primeros borradores de 1995 del documento PEP — an Extension Mechanism for HTTP (el cual propone el Protocolo de Extensión de Protocolo, abreviado PEP) los hizo el World Wide Web Consortium y se envió al Internet Engineering Task Force. El PEP inicialmente estaba destinado a convertirse en un rango distintivo de HTTP/1.2.​ En borradores posteriores, sin embargo, se eliminó la referencia a HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, incluye en gran medida a PEP. Se publicó en febrero de 2000.

HTTP/2 (mayo de 2015)

En el año 2012 aparecen los primeros borradores de la nueva versión de HTTP (HTTP/2). Esta nueva versión no modifica la semántica de aplicación de http (todos los conceptos básicos continúan sin cambios). Sus mejoras se enfocan en como se empaquetan los datos y en el transporte. Por ejemplo, añade el uso de una única conexión, la compresión de cabeceras o el servicio 'server push'. Los exploradores más importantes solo soportan HTTP 2.0 sobre TLS usando la extensión ALPN​ que requiere TLSv1.2 o superior.​

HTTP/3 (Octubre de 2018)

HTTP/3 es el sucesor propuesto de HTTP/2,​​ que ya está en uso en la web, utilizando UDP en lugar de TCP para el protocolo de transporte subyacente. Al igual que el HTTP/2, no es obsoleto en las versiones principales anteriores del protocolo. El soporte para HTTP/3 fue agregado a Cloudflare y Google Chrome en septiembre de 2019,​​ y puede ser habilitado en las versiones estables de Chrome y Firefox.​

Véase también

• Transport Layer Security
• HTTPS
• HTTP Strict Transport Security
• HTTP (P2P)
• HTTP/2
• .har

Enlaces externos

• HTTP - Hypertext Transfer Protocol. W3C
• HTTP Made Really Easy. byJames Marshall, 1997
• Validación de HTTP Headers Verificación de URL Online
• Prueba de compatibilidad HTTP/2

• Datos: Q8777
• Multimedia: Hypertext Transfer Protocol / Q8777