Protocolo HTTP

ndice
1. Introduccin
2. Sintaxis de la peticin
3. Mensaje HTTP
3.1. Peticin
3.2. Respuesta
3.3. Mtodos
3.3.1. Mtodo OPTIONS
3.3.2. Mtodo GET
3.3.3. Mtodo HEAD
3.3.4. Mtodo POST
3.3.5. Mtodo PUT
3.3.6. Mtodo DELETE
3.3.7. Mtodo TRACE
3.4. Cabeceras
3.4.1. Generales
3.4.2. De peticin
3.4.3. De respuesta
3.4.4. De entidad


1. Introduccin
El protocolo de transferencia de hipertexto (HyperText Transfer Protocol) es un
protocolo del nivel de aplicacin usado para la transferencia de informacin entre
sistemas, de forma clara y rpida. Este protocolo ha sido usado por el World-Wide Web
desde 1990.
Este protocolo permite usar una serie de mtodos para indicar la finalidad de la peticin.
Se basa en otros conceptos y estndares como Uniform Resource Identifier (URI),
Uniform Resource Location (URL) y Uniform Resource Name (URN), para indicar el
recurso al que hace referencia la peticin. Los mensajes se pasan con un formato similar
al usado por el Internet Mail y el Multipurpose Internet Mail Extensions (MIME).
El protocolo HTTP se basa en un paradigma de peticiones y respuestas. Un cliente enva
una peticin en forma de mtodo, una URI, y una versin de protocolo seguida de los
modificadores de la peticin de forma parecida a un mensaje MIME, informacin sobre
el cliente y al final un posible contenido. El servidor contesta con una lnea de estado
que incluye la versin del protocolo y un cdigo que indica xito o error, seguido de la
informacin del servidor en forma de mensaje MIME y un posible contenido.
Generalmente es el cliente el que inicia la comunicacin HTTP y consiste en la peticin
de un recurso del servidor. Puede hacerse de forma directa al servidor o a travs de
intermediarios.
Se han utilizado los protocolos HTTP/0.9, HTTP/1.0 [2] y HTTP/1.1 [6].

2. Sintaxis de la peticin
El esquema ``http'' se usa para localizar recursos en la red por medio del protocolo http.
La sintaxis de la peticin es la siguiente:
``http:'' ``//'' direccin [ ``:'' puerto ] [ path ]
Donde direccin es el nombre de un dominio de Internet o una direccin IP, el puerto
es un nmero que indica el puerto al que se enva la peticin y el path indica el recurso
al que se accede.
Si no se indica un nmero de puerto, por defecto se supone que se accede al puerto 80.
Si no se indica un path, entonces se supone que este es ``/''.

3. Mensaje HTTP
Un mensaje http consiste en una peticin de un cliente al servidor y en la respuesta del
servidor al cliente.
Las peticiones y respuestas pueden ser simples o completas. La diferencia es que en las
peticiones y respuestas completas se envan cabeceras y un contenido. Este contenido se
pone despus de las cabeceras dejando una lnea vaca entre las cabeceras y el
contenido. En el caso de peticiones simples, slo se puede usar el mtodo GET y no hay
contenido. Si se trata de una respuesta simple, entonces sta slo consta de contenido.
Esta diferenciacin entre simples y completas se tiene para que el protocolo HTTP/1.0
pueda atender peticiones y enviar respuestas del protocolo HTTP/0.9.

3.1 Peticin
Una peticin de un cliente a un servidor ha de incluir el mtodo que se aplica al recurso,
el identificador del recurso y la versin del protocolo que usa para realizar la peticin.
Para mantener la compatibilidad con el protocolo HTTP/0.9 se permite una peticin
simple con el formato:
``GET'' SP URI CRLF
Donde SP es un espacio, URI es la URI del recurso al que hace referencia la peticin y
CRLF es un retorno de carro y nueva lnea.
En el caso de que la peticin se haga con el protocolo HTTP/1.0 o con el protocolo
HTTP/1.1 la peticin sigue el formato:
Lnea de peticin
*(Cabeceras)
CRLF
[Contenido]
La lnea de peticin comienza indicando el mtodo, seguido de la URI de la
peticin y la versin del protocolo, finalizando la lnea con CRLF:
Mtodo SP URI de la peticin SP Versin del protocolo CRLF
En el caso del protocolo HTTP/0.9 slo se permite el mtodo GET, con el protocolo
HTTP/1.0 GET, POST y HEAD y con el protocolo HTTP/1.1 OPTIONS, GET, HEAD,
POST, PUT, DELETE y TRACE. En caso de que un servidor tenga implementado un
mtodo, pero no est permitido para el recurso que se pide, entonces ha de devolver un
cdigo de estado 405 (mtodo no permitido). Si lo que ocurre es que no tiene
implementado el mtodo, entonces devuelve un cdigo 501 (no implementado). Los
nicos mtodos que deben soportar los servidores de forma obligatoria son los mtodos
GET y HEAD.
En el apartado de cabeceras, stas pueden ser de tres tipos: cabeceras generales (punto
A.3.4), de peticin (punto A.3.5) y de entidad (punto A.3.7). Las cabeceras generales
son las que se aplican tanto a peticiones como a respuestas, pero no al contenido que se
transmite. Las cabeceras de peticin permiten al cliente pasar informacin al servidor
sobre la peticin y sobre el cliente. Las cabeceras de entidad permiten definir
informacin adicional sobre el contenido que se transmite y en caso de que no haya
contenido, sobre el recurso al que se quiere acceder con la peticin.
El contenido (si est presente) est en un formato con una codificacin definida en las
cabeceras de entidad.

3.2 Respuesta
Despus de recibir e interpretar una peticin, el servidor debe responder con un mensaje
HTTP. Este mensaje tiene el siguiente formato:
Lnea de estado
*( Cabeceras )
CRLF
[ Contenido ]
La lnea de estado es la primera lnea de la respuesta y consiste en la versin de
protocolo que se utiliza, seguida de una indicacin de estado numrica a la que puede ir
asociada una frase explicativa. El formato es el siguiente:
Versin del protocolo SP Cdigo de estado SP Frase explicativa CRLF
El cdigo de estado es un nmero de 3 dgitos que indica si la peticin ha sido atendida
satisfactoriamente o no, y en caso de no haber sido atendida, indica la causa. Los
cdigos se dividen en cinco clases definidas por el primer dgito del cdigo de estado.
As tenemos:
1xx: Informativo. La peticin se recibe y sigue el proceso. Esta familia de
respuestas indican una respuesta provisional. Este tipo de respuesta est formada
por la lnea de estado y las cabeceras. Un servidor enva este tipo de respuesta en
casos experimentales.
2xx: xito. La accin requerida por la peticin ha sido recibida, entendida y
aceptada.
3xx: Redireccin. Para completar la peticin se han de tomar ms acciones.
4xx: Error del cliente. La peticin no es sintcticamente correcta y no se puede
llevar a cabo.
5xx: Error del servidor. El servidor falla al atender la peticin que
aparentemente es correcta.
Algunos de los cdigos ms comnmente usados y las frases asociadas son:
100, continuar.
101, cambio de protocolo.
200, xito.
201, creado.
202, aceptado.
203, informacin no autoritativa.
204, sin contenido.
205, contenido reestablecido.
206, contenido parcial.
300, mltiples elecciones.
301, movido permanentemente.
302, movido temporalmente.
303, ver otros.
304, no modificado.
305, usar proxy.
400, peticin errnea.
401, no autorizado.
402, pago requerido.
403, prohibido.
404, no encontrado.
405, mtodo no permitido.
406, no se puede aceptar.
407, se requiere autentificacin proxy.
408, lmite de tiempo de la peticin.
409, conflicto.
410, gone.
411, tamao requerido.
412, falla una precondicin.
413, contenido de la peticin muy largo.
414, URI de la peticin muy largo.
415, campo media type requerido.
500, error interno del servidor.
501, no implementado.
502, puerta de enlace errnea.
503, servicio no disponible.
504, tiempo lmite de la puerta de enlace.
505, versin de protocolo HTTP no soportada.
La frase explicativa, es eso, una frase corta que explica el cdigo de estado enviado al
cliente.
Se pueden usar ms cdigos, pero las aplicaciones HTTP no tienen que conocer todos
los cdigos definidos y su significado, pero s estn obligadas a conocer su clase y tratar
los cdigos desconocidos como el primer cdigo de la clase (x00).
En cuanto a las cabeceras de la respuesta, son de tres tipos: las cabeceras generales
(punto A.3.4), las cabeceras de la respuesta (punto A.3.6) y las cabeceras de entidad
(apartado A.3.7).
Las cabeceras de respuesta permiten al servidor enviar informacin adicional al cliente
sobre la respuesta. Estos campos dan informacin sobre el servidor y acceso al recurso
pedido.

3.3 Mtodos
Un mtodo se dice que es seguro si no provocan ninguna otra accin que no sea la de
devolver algo (no produce efectos laterales). Estos mtodos son el mtodo GET y el
mtodo HEAD. Para realizar acciones inseguras (las que afectan a otras acciones) se
pueden usar los mtodos POST, PUT y DELETE. Aunque esto est definido as, no se
puede asegurar que un mtodo seguro no produzca efectos laterales, porque depende de
la implementacin del servidor.
Un mtodo es idempotente si los efectos laterales para N peticiones son los mismos que
para una sola peticin. Los mtodos idempotentes son los mtodos GET, HEAD, PUT y
DELETE.

3.3.1 Mtodo OPTIONS
Este mtodo representa un peticin de informacin sobre las opciones de comunicacin
disponibles en la cadena peticin-respuesta identificada por la URI de la peticin. Esto
permite al cliente conocer las opciones y requisitos asociados con un recurso o las
capacidades del servidor.
La respuesta slo debe incluir informacin sobre las opciones de comunicacin.

Si la URI es ``*'', entonces la peticin se aplica al servidor como un conjunto. Es decir,
contesta caractersticas opcionales definidas por el servidor, extensiones del protocolo,
...
3.3.2 Mtodo GET
El mtodo GET requiere la devolucin de informacin al cliente identificada por la
URI. Si la URI se refiere a un proceso que produce informacin, se devuelve la
informacin y no la fuente del proceso.
El mtodo GET pasa a ser un GET condicional si la peticin incluye las cabeceras If-
Modified-Since, If-Unmodified-Since, If-Match, If-None-Match o If-Range.
Estas cabeceras hacen que el contenido de la respuesta se transmita slo si se cumplen
unas condiciones determinadas por esas cabeceras. Esto se hico para reducir el trfico
en las redes.
Tambin hay un mtodo GET parcial, con el que se enva slo parte del contenido del
recurso requerido. Esto ocurre cuando la peticin tiene una cabecera Range. Al igual
que el mtodo GET condicional, el mtodo GET parcial se cre para reducir el trfico
en la red.
3.3.3 Mtodo HEAD
El mtodo HEAD es igual que el mtodo GET, salvo que el servidor no tiene que
devolver el contenido, slo las cabeceras. Estas cabeceras que se devuelven en el
mtodo HEAD deberan ser las mismas que las que se devolveran si fuese una peticin
GET.
Este mtodo se puede usar para obtener informacin sobre el contenido que se va a
devolver en respuesta a la peticin. Se suele usar tambin para chequear la validez de
links, accesibilidad y modificaciones recientes.
3.3.4 Mtodo POST
El mtodo POST se usa para hacer peticiones en las que el servidor destino acepta el
contenido de la peticin como un nuevo subordinado del recurso pedido. El mtodo
POST se cre para cubrir funciones como la de enviar un mensaje a grupos de usuarios,
dar un bloque de datos como resultado de un formulario a un proceso de datos, aadir
nuevos datos a una base de datos, ...
La funcin llevada a cabo por el mtodo POST est determinada por el servidor y suele
depender de la URI de la peticin. El resultado de la accin realizada por el mtodo
POST puede ser un recurso que no sea identificable mediante una URI.
3.3.5 Mtodo PUT
El mtodo PUT permite guardar el contenido de la peticin en el servidor bajo la URI
de la peticin. Si esta URI ya existe, entonces el servidor considera que esta peticin
proporciona una versin actualizada del recurso. Si la URI indicada no existe y es vlida
para definir un nuevo recurso, el servidor puede crear el recurso con esa URI. Si se crea
un nuevo recurso, debe responder con un cdigo 201 (creado), si se modifica se contesta
con un cdigo 200 (OK) o 204 (sin contenido). En caso de que no se pueda crear el
recurso se devuelve un mensaje con el cdigo de error apropiado.
La principal diferencia entre POST y PUT se encuentra en el significado de la URI. En
el caso del mtodo POST, la URI identifica el recurso que va a manejar en contenido,
mientras que en el PUT identifica el contenido.
Un recurso puede tener distintas URI.
3.3.6 Mtodo DELETE
Este mtodo se usa para que el servidor borre el recurso indicado por la URI de la
peticin. No se garantiza al cliente que la operacin se lleve a cabo aunque la respuesta
sea satisfactoria.
3.3.7 Mtodo TRACE
Este mtodo se usa para saber si existe el receptor del mensaje y usar la informacin
para hacer un diagnstico. En las cabeceras el campo Via sirve para obtener la ruta que
sigue el mensaje. Mediante el campo Max-Forwards se limita el nmero de pasos
intermedios que puede tomar. Esto es til para evitar bucles entre los proxy.
La peticin con el mtodo TRACE no tiene contenido.

3.4 Cabeceras
3.4.1 Generales
Los campos de este tipo de cabeceras se aplican tanto a las peticiones como a las
respuestas, pero no al contenido de los mensajes.
Estas cabeceras son:
Cache-Control, son directivas que se han de tener en cuenta a la hora de
mantener el contenido en una cach.
Connection, permite especificar opciones requeridas para una conexin.
Date, representa la fecha y la hora a la que se cre el mensaje.
Pragma, usado para incluir directivas de implementacin.
Transfer-Encoding, indica la codificacin aplicada al contenido.
Upgrade, permite al cliente especificar protocolos que soporta.
Via, usado por pasarelas y proxies para indicar los pasos seguidos.
3.4.2 De peticin
Este tipo de cabeceras permite al cliente pasar informacin adicional al servidor sobre
la peticin y el propio cliente.
Estas cabeceras son las siguientes:
Accept, indican el tipo de respuesta que acepta.
Accept-Charset, indica los conjuntos de caracteres que acepta.
Accept-Encoding, que tipo de codificacin acepta.
Accept-Language, tipo de lenguaje de la respuesta que se prefiere.
Authorization, el agente de usuario quiere autentificarse con el servidor.
From, contiene la direccin de correo que controla en agente de usuario.
Host, especifica la mquina y el puerto del recurso pedido.
If-Modified-Since, para el GET condicional.
If-Match, para el GET condicional.
If-None-Match, para el GET condicional.
If-Range, para el GET condicional.
If-Unmodified-Since, para el GET condicional.
Max-Forwards, indica el mximo nmero de elementos por los que pasa.
Proxy-Authorization, permite que el cliente se identifique a un proxy.
Range, establece un rango de bytes del contenido.
Referer, indica la direccin donde obtuvo la URI de la peticin.
User-Agent, informacin sobre el agente que genera la peticin.

2.4.3 De respuesta
Permiten al servidor pasar informacin adicional al cliente sobre la respuesta, el propio
servidor y el recurso solicitado.

Son los campos:
Age, estimacin del tiempo transcurrido desde que se cre la respuesta.
Location, se usa par a redirigir la peticin a otra URI.
Proxy-Authenticate, ante una respuesta con el cdigo 407 (autentificacin
proxy requerida), indica el esquema de autentificacin.
Public, da la lista de mtodos soportados por el servidor.
Retry-After, ante un servicio no disponible da una fecha para volver a
intentarlo.
Server, informacin sobre el servidor que maneja las peticiones.
Vary, indica que hay varias respuestas y el servidor ha escogido una.
Warning, usada para aportar informacin adicional sobre el estado de la
respuesta.
WWW-Authenticate, indica el esquema de autentificacin y los parmetros
aplicables a la URI.

3.4.4 Cabeceras de entidad
Como su nombre indica, los campos de este tipo aportan informacin sobre el contenido
del mensaje o si no hay contenido, sobre el recurso al que hace referencia la URI de la
peticin.
Los campos de este tipo son:
Allow, da los mtodos soportados por el recurso designado por la URI.
Content-Base, indica la URI base para resolver las URI relativas.
Content-Encoding, indica una codificacin adicional aplicada al contenido (a
parte de la aplicada por el tipo).
Content-Language, describe el idioma del contenido.
Content-Length, indica el tamao del contenido del mensaje.
Content-Location, da informacin sobre la localizacin del recurso que da
el contenido del mensaje.
Content-MD5, es un resumen en formato MD5 (RFC 1864) para chequear la
integridad del contenido.
Content-Range, en un GET parcial, indica la posicin del contenido.
Content-Type, indica el tipo de contenido que es.
Etag, define una marca para el contenido asociado.
Expires, indica la fecha a partir de la cual la respuesta deja de ser vlida.
Last-Modified, indica la fecha de la ltima modificacin.