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. 1 [ ]
Propiedades de los métodos de petición
La
La
petici
respues
Métod ón Segur Idempote Cacheab
RFC ta tiene
o tiene o nte le
carga
carga
útil
útil
RFC 91
GET Opcional Sí Sí Sí Sí
10
RFC 91
HEAD Opcional No Sí Sí Sí
10
RFC 91
POST Sí Sí No No Sí
10
RFC 91
PUT Sí Sí No Sí No
10
RFC 91
DELETE Opcional Sí No Sí No
10
CONNE RFC 91
Opcional Sí No No No
CT 10
OPTION RFC 91
Opcional Sí Sí Sí No
S 10
RFC 91
TRACE No Sí Sí Sí No
10
RFC 57
PATCH Sí Sí No No No
89
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.)2 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».3 [ ]
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 ).2 [ ]
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.2 [ ]
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).2
[ ]
DELETE
Borra el recurso especificado.2
[ ]
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.4 [ ]
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.2 [ ]
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).4 [ ]
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.5 [ ]
Métodos de WebDAV
Artículo principal: WebDAV
WebDAV añade los métodos siguientes:
COPY
Copia un recurso de una URI a otra.6 [ ]
MOVE
Mueve un recurso de una URI a otra.6 [ ]
LOCK
6
Bloquea un recurso. [ ]
UNLOCK
Desbloquea un recurso.6 [ ]
MKCOL
Crea una nueva colección de recursos en la ubicación especificada en
el Request-URI .6
[ ]
PROPFIND
6
Obtiene las propiedades de un recurso. [ ]
PROPPATCH
6
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
Artículo
principal: Protocolo de
iniciación de sesión
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).