Hypertext
Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto)
es el protocolo usado en cada transacción de la World Wide Web. HTTP fue
desarrollado por el World Wide Web Consortium y la Internet EngineeringTaskForce,
colaboración que culminó en 1999 con la publicación de una serie de RFC, el más
importante de ellos es 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. Es un protocolo orientado a transacciones y sigue el
esquema petición-respuesta entre un cliente y un servidor. Al cliente que
efectúa la petición (un navegador web o un spider) se lo conoce como "useragent"
(agente del usuario). A la información transmitida se la llama recurso y se la
identifica mediante un localizador uniforme de recursos (URL). Los recursos
pueden ser archivos, el resultado de la ejecución de un programa, una consulta
a una base de datos, la traducción automática de un documento, etc.
HTTP
es un protocolo sin estado, es decir, 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.
Una
transacción HTTP está formada por un encabezado seguido, opcionalmente, por una
línea en blanco y algún dato. El encabezado especificará cosas como la acción
requerida del servidor, o el tipo de dato retornado, o el código de estado.
El
uso de campos de encabezados enviados en las transacciones HTTP le dan gran
flexibilidad al protocolo. Estos campos permiten que se envíe información
descriptiva en la transacción, permitiendo así la autenticación, cifrado e
identificación de usuario.
Un
encabezado es un bloque de datos que precede a la información propiamente
dicha, por lo que muchas veces se hace referencia a él como metadato —porque
tiene datos sobre los datos—.
Si
se reciben líneas de encabezado del cliente, el servidor las coloca en las
variables de entorno de CGI con el prefijo HTTP_ seguido del nombre del
encabezado. Cualquier carácter guion ( - ) del nombre del encabezado se
convierte a caracteres "_".
El
servidor puede excluir cualquier encabezado que ya esté procesado, como
Authorization, Content-type y Content-length. El servidor puede elegir excluir
alguno o todos los encabezados si incluirlos si se excede algún límite del
entorno de sistema. Ejemplos de esto son las variables HTTP_ACCEPT y
HTTP_USER_AGENT.
• HTTP_ACCEPT. Los tipos MIME que el
cliente aceptará, dados los encabezados HTTP. Otros protocolos quizás necesiten
obtener esta información de otro lugar. Los elementos de esta lista deben estar
separados por una coma, como se dice en la especificación HTTP: tipo, tipo.
• HTTP_USER_AGENT. El navegador que
utiliza el cliente para realizar la petición. El formato general para esta
variable es: software/versión biblioteca/versión.
El
servidor envía al cliente:
• Un código de estado que indica si la
petición fue correcta o no. Los códigos de error típicos indican que el archivo
solicitado no se encontró, que la petición no se realizó de forma correcta o
que se requiere autenticación para acceder al archivo.
• La información propiamente dicha. Como
HTTP permite enviar documentos de todo tipo y formato, es ideal para transmitir
multimedia, como gráficos, audio y video. Esta libertad es una de las mayores
ventajas de HTTP.
• Información sobre el objeto que se
retorna.
VERSIONES
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.
HTTP/1.1
(junio de 1999)12
Versión
actual; 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-Tripdelay por cada petición.
HTTP/1.2
Los
primeros borradores de 1995 del documento PEP — anExtensionMechanismfor HTTP
(el cuál propone el Protocolo de Extensión de Protocolo, abreviado PEP) los
hizo el World Wide Web Consortium y se envió al Internet EngineeringTaskForce.
El PEP inicialmente estaba destinado a convertirse en un rango distintivo de
HTTP/1.2.3 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 define 8 métodos (algunas veces referido como "verbos")
que indica la acción que desea que se efectúe sobre el recurso identificado. Lo
que este recurso representa, si los datos pre-existentes o datos que se generan
de forma dinámica, depende de la aplicación del servidor. A menudo, el recurso
corresponde a un archivo o la salida de un ejecutable que residen en el
servidor.
HEAD
Pide una
respuesta idéntica a la que correspondería a una petición GET, pero sin el
cuerpo de la respuesta. Esto es útil para la recuperación de meta-información
escrita en los encabezados de respuesta, sin tener que transportar todo el
contenido.
GET
Pide una
representación del recurso especificado. Por seguridad no debería ser
usado por aplicaciones que causen efectos ya que transmite información a través
de la URI agregando parámetros a la URL.
Ejemplo:
GET /images/logo.png HTTP/1.1 obtiene un recurso llamado
logo.png
Ejemplo con
parámetros:
/index.php?page=main&lang=es
POST
Somete los
datos a que sean procesados para el recurso identificado. Los datos se
incluirán en el cuerpo de la petición. Esto puede resultar en la creación de un
nuevo recurso o de las actualizaciones de los recursos existentes o ambas
cosas.
PUT
Sube, carga
o realiza un upload de un recurso especificado (archivo), es el camino más
eficiente para subir archivos a un servidor, esto es porque en POST utiliza un mensaje
multiparte y el mensaje es decodificado por el servidor. En contraste, el
método PUT te permite escribir un archivo en una conexión socket establecida
con el servidor.
La
desventaja del método PUT es que los servidores de hosting compartido no lo
tienen habilitado.
Ejemplo:
PUT /path/filename.html HTTP/1.1
DELETE
Borra el
recurso especificado.
TRACE
Este método
solicita al servidor que envíe de vuelta en un mensaje de respuesta, en la
sección del cuerpo de entidad, toda la data que reciba del mensaje de
solicitud. Se utiliza con fines de comprobación y diagnostico.
OPTIONS
Devuelve los
métodos HTTP que el servidor soporta para un URL especifico.Esto puede ser
utilizado para comprobar la funcionalidad de un servidor web mediante petición
en lugar de un recurso especifico
CONNECT
Se utiliza
para saber si se tiene acceso a un host, no necesariamente la peticion llega al
servidor, este metodo se utiliza pricipalmente para saber si un proxy nos da
acceso a un host bajo condiciones especiales, como por ejemplo
"corrientes" de datos bidireccionales encriptadas (como lo requiere
SSL).
] Ejemplo de un diálogo HTTP
Para obtener un recurso con el
http://www.example.com/index.html
- Se abre una conexión al host www.example.com, puerto 80 que es el puerto por defecto para HTTP.
- Se envía un mensaje en el estilo siguiente:
GET
/index.html HTTP/1.1
Host: www.example.com
User-Agent: nombre-cliente
[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>
<body>
<h1>Página principal de
tuHost</h1>
(Contenido)
.
.
.
</body>
</html>
