Hypertext Transfer Protocol

Hypertext Transfer Protocol o HTTP (en espaol protocolo de transferencia de hipertexto) es el protocolo usado en cada transaccin de la World Wide Web. HTTP
fue desarrollado por el World Wide Web Consortium y la
Internet Engineering Task Force, colaboracin que culmin en 1999 con la publicacin de una serie de RFC,
el ms importante de ellos es el RFC 2616 que especica la versin 1.1. HTTP dene la sintaxis y la semntica
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 peticin-respuesta entre un cliente y un servidor. Al
cliente que efecta la peticin (un navegador web o un
spider) se lo conoce como user agent (agente del usuario). A la informacin transmitida se la llama recurso y se
la identica mediante un localizador uniforme de recursos (URL). El resultado de la ejecucin de un programa,
una consulta a una base de datos, la traduccin automtica de un documento, etc.

jo HTTP_ seguido del nombre del encabezado. Cualquier

carcter 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 algn
lmite 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 quizs necesiten obtener esta informacin de
otro lugar. Los elementos de esta lista deben estar
separados por una coma, como se dice en la especicacin HTTP: tipo, tipo.
HTTP_USER_AGENT. El navegador que utiliza
el cliente para realizar la peticin. El formato general para esta variable es: software/versin biblioteca/versin.

HTTP es un protocolo sin estado, es decir, que no guarda ninguna informacin sobre conexiones anteriores. El
desarrollo de aplicaciones web necesita frecuentemente
mantener estado. Para esto se usan las cookies, que es in- El servidor enva al cliente:
formacin que un servidor puede almacenar en el sistema
Un cdigo de estado que indica si la peticin fue cocliente. Esto le permite a las aplicaciones web instituir la
rrecta o no. Los cdigos de error tpicos indican que
nocin de sesin, y tambin permite rastrear usuarios ya
el archivo solicitado no se encontr, que la peticin
que las cookies pueden guardarse en el cliente por tiempo
no se realiz de forma correcta o que se requiere auindeterminado.
tenticacin para acceder al archivo.

La informacin propiamente dicha. Como HTTP

permite enviar documentos de todo tipo y formato,
es ideal para transmitir multimedia, como grcos,
audio y video. Esta libertad es una de las mayores
ventajas de HTTP.

Transacciones HTTP

Una transaccin HTTP est formada por un encabezado

seguido, opcionalmente, por una lnea en blanco y algn
Informacin sobre el objeto que se retorna.
dato. El encabezado especicar cosas como la accin
requerida del servidor, o el tipo de dato retornado, o el
Hay que tener en cuenta que la lista no es una lista comcdigo de estado.
pleta de los campos de encabezado y que todos ellos slo
El uso de campos de encabezados enviados en las transac- tienen sentido en una direccin.
ciones HTTP le dan gran exibilidad al protocolo. Estos
campos permiten que se enve informacin descriptiva en
la transaccin, permitiendo as la autenticacin, cifrado e
2 Versiones
identicacin de usuario.
Un encabezado es un bloque de datos que precede a la informacin propiamente dicha, por lo que muchas veces se
hace referencia a l como metadato porque tiene datos
sobre los datos.

HTTP ha pasado por mltiples versiones del protocolo,

muchas de las cuales son compatibles con las anteriores.
El RFC 2145 describe el uso de los nmeros de versin
de HTTP. El cliente le dice al servidor al principio de la
Si se reciben lneas de encabezado del cliente, el servidor peticin la versin que usa, y el servidor usa la misma o
las coloca en las variables de entorno de CGI con el pre- una anterior en su respuesta.
1

4 MTODOS DE PETICIN

0.9 Obsoleta. Soporta slo un comando, GET, y adems

no especica el nmero de versin HTTP. No soporta cabeceras. Como esta versin no soporta POST,
el cliente no puede enviarle mucha informacin al
servidor.
HTTP/1.0 (mayo de 1996) Esta es la primera revisin
del protocolo que especica su versin en las comunicaciones, y todava se usa ampliamente, sobre todo en servidores proxy.
HTTP/1.1 (junio de 1999)[1][2]
Versin actual; las conexiones persistentes estn activadas por defecto y funcionan bien con
los proxies. Tambin permite al cliente enviar
mltiples peticiones a la vez por la misma conexin (pipelining) lo que hace posible eliminar el tiempo de Round-Trip delay por cada peticin.

Un pedido HTTP usando telnet. El pedido (request), cabeceras de respuesta (response headers) y el cuerpo de la respuesta
(response body) estn resaltados.

sobre el recurso identicado. Lo que este recurso representa, si los datos pre-existentes o datos que se generan de
HTTP/1.2 Los primeros borradores de 1995 del docu- forma dinmica, depende de la aplicacin del servidor. A
mento PEP an Extension Mechanism for HTTP menudo, el recurso corresponde a un archivo o la salida
(el cul propone el Protocolo de Extensin de Pro- de un ejecutable que residen en el servidor.
tocolo, abreviado PEP) los hizo el World Wide Web
Consortium y se envi al Internet Engineering Task
HEAD Pide una respuesta idntica a la que corresponForce. El PEP inicialmente estaba destinado a condera a una peticin GET, pero sin el cuerpo de la
vertirse en un rango distintivo de HTTP/1.2.[3] En
respuesta. Esto es til para la recuperacin de metaborradores posteriores, sin embargo, se elimin la
informacin escrita en los encabezados de respuesta,
referencia a HTTP/1.2. El RFC 2774 (experimensin tener que transportar todo el contenido.
tal), HTTP Extension Framework, incluye en gran
medida a PEP. Se public en febrero de 2000.
GET Pide una representacin del recurso especicado.
Por seguridad no debera ser usado por aplicaciones
que causen efectos ya que transmite informacin a
3 Ejemplo de un dilogo HTTP
travs de la URI agregando parmetros a la URL.
La peticin puede ser simple, es decir en una linea
Para obtener un recurso con el URL http://www.
o compuesta de la manera que muestra el ejemplo.
example.com/index.html
Ejemplo:
1. Se abre una conexin al host www.example.com,
GET /images/logo.png HTTP/1.1 obtiene un recurso
puerto 80 que es el puerto por defecto para HTTP.
llamado logo.png
2. Se enva un mensaje en el estilo siguiente:
Ejemplo con parmetros:
GET /index.html HTTP/1.1 Host: www.example.com
/index.php?page=main&lang=es
User-Agent: nombre-cliente [Lnea en blanco]
La respuesta del servidor est formada por encabezados
seguidos del recurso solicitado, en el caso de una pgina POST Enva los datos para que sean procesados por el
recurso identicado. Los datos se incluirn en el
web:
cuerpo de la peticin. Esto puede resultar en la creaHTTP/1.1 200 OK Date: Fri, 31 Dec 2003 23:59:59
cin de un nuevo recurso o de las actualizaciones de
GMT Content-Type: text/html Content-Length: 1221
los recursos existentes o ambas cosas.
<html> <body> <h1>Pgina principal de tuHost</h1>
(Contenido) . . . </body> </html>
PUT Sube, carga o realiza un upload de un recurso especicado (archivo), es el camino ms eciente para
subir archivos a un servidor, esto es porque en POST
4 Mtodos de peticin
utiliza un mensaje multiparte y el mensaje es decodicado por el servidor. En contraste, el mtodo
HTTP dene 8 mtodos (algunas veces referido como
PUT te permite escribir un archivo en una conexin
verbos) que indica la accin que desea que se efecte
socket establecida con el servidor.

3
La desventaja del mtodo PUT es que los servidores de
hosting compartido no lo tienen habilitado.
Ejemplo:
PUT /path/lename.html HTTP/1.1
DELETE Borra el recurso especicado.
TRACE Este mtodo solicita al servidor que enve de
vuelta en un mensaje de respuesta, en la seccin del
cuerpo de entidad, toda la data que reciba del mensaje de solicitud. Se utiliza con nes de comprobacin y diagnstico.
OPTIONS Devuelve los mtodos HTTP que el servidor
soporta para un URL especco.Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante peticin en lugar de un recurso
especco.
CONNECT Se utiliza para saber si se tiene acceso a un
host, no necesariamente la peticin llega al servidor,
este mtodo se utiliza principalmente 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).

Cdigos de respuesta
1xx Mensajes

2xx Operacin exitosa

3xx Redirecin

4xx Error por parte del cliente

5xx Error del servidor

Vase tambin
Transport Layer Security
HTTPS
HTTP Strict Transport Security

7 Referencias
[1] Enero de 1997. Se publica la primera versin de la especicacin HTTP/1.1
[2] Junio de 1999. Publicada la ltima versin de la especicacin HTTP/1.1
[3] PEP: An Extension Mechanism for HTTP. Cita: For experimental purposes, PEP-compatibility is equated with
HTTP/1.2.

8 Enlaces externos
RFC-2616
HTTP - Hypertext Transfer Protocol. W3C
HTTP Made Really Easy. byJames Marshall, 1997
Validacin de HTTP Headers Vericacin de URL
Online

9 TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

Text and image sources, contributors, and licenses

9.1

Text

Hypertext Transfer Protocol Fuente: http://es.wikipedia.org/wiki/Hypertext%20Transfer%20Protocol?oldid=78376724 Colaboradores:

AstroNomo, Andre Engels, Maveric149, Iranzop, Macar, Nnss, Moriel, Sauron, JorgeGG, Agomez, Angus, Sanbec, Dodo, Triku, Ascnder, Sms, Cookie, Murphy era un optimista, Barcex, Jmcontreras, Jag2k4, Hildergarn, Ikks, JCCO, Toad32767, Periku, Niqueco,
Renabot, FAR, Caos, Soulreaper, Yurik, Airunp, Taichi, Rembiapo pohyiete (bot), Magister Mathematicae, Kokoo, Viko, Orgullobot,
RobotQuistnix, Platonides, Superzerocool, Yrbot, Oscar ., FlaBot, Vitamine, YurikBot, Mortadelo2005, GermanX, KnightRider, Eloy,
JRGL, Eskimbot, Gnovaro, Maldoror, Grizzly Sigma, Alcojol, Er Komandante, Cheveri, Tomatejc, Jcarlos77, Siabef, BOTpolicia, CEMbot, Baiji, Antur, Mcetina, Escarlati, FrancoGG, Thijs!bot, Locovich, Isha, Egaida, Xoneca, Atardecere, Mpeinadopa, JAnDbot, Jugones55, Death Master, BetBot, Muro de Aguas, TXiKiBoT, Elisardojm, Humberto, Netito777, Claudio Elias, Rei-bot, Idioma-bot, Plux,
Manuel Trujillo Berges, Biasoli, Tradeos, AlnoktaBOT, Cinevoro, VolkovBot, Technopat, Queninosta, Rogeliovelasquez, Matdrodes,
Herresuelo, Shooke, Lucien leGrey, Barri, Rafael.heras, Muro Bot, Numbo3, Dinopmi, SieBot, Mushii, Ctrl Z, Ensada, Cobalttempest,
CoverUp, STBot, OboeCrack, Greek, Jmaquino, DorganBot, Tirithel,
robot, Jarisleif, Carlos56, HUB, DragonBot, Botelln, Leonpolanco, Pan con queso, Clouder, Apj, Valerypipettu, Valentin estevanez navarro, SilvonenBot, Camilo, UA31, Shalbat, Vaites, AVBOT,
Lohan21, David0811, Logo, Louperibot, MastiBot, Gustavo.ramos, Angel GN, MarcoAurelio, Diegusjaimes, MelancholieBot, Arjuno3,
Andreasmperu, Luckas-bot, Jotterbot, SuperBraulio13, Ortisa, Obersachsebot, Xqbot, Jkbw, Rubinbot, Dreitmen, Irbian, Surfaz, Botarel,
RubiksMaster110, ManuBOT15, Vubo, AnselmiJuan, Hateinblood, Orion sae, LoliBot, PatruBOT, Tarawa1943, GrouchoBot, EmausBot,
Savh, Jesus Belinchon, HRoestBot, Sergio Andres Segovia, Katherinee21 6, Grillitus, KLBot, Rubpe19, Amerikaos, Albertojuanse, WikitanvirBot, Dr Doofenshmirtz, Wikipedista-perfeccionista, MerlIwBot, KLBot2, Travelour, Allan Aguilar, Elhacedor, Harpagornis, Elvisor,
Helmy oved, Makecat-bot, Samuel nielsen, Martin tellez aguirre, Addbot, Mettallzoar, JacobRodrigues, Carocad, Loba13 y Annimos: 343

9.2

Images

Archivo:Commons-emblem-question_book_orange.svg
Fuente:
http://upload.wikimedia.org/wikipedia/commons/1/1f/
Commons-emblem-question_book_orange.svg Licencia: CC-BY-SA-3.0 Colaboradores: <a href='//commons.wikimedia.org/
wiki/File:Commons-emblem-issue.svg'
class='image'><img
alt='Commons-emblem-issue.svg'
src='//upload.wikimedia.org/
wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/25px-Commons-emblem-issue.svg.png'
width='25'
height='25'
srcset='//upload.wikimedia.org/wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/38px-Commons-emblem-issue.svg.png
1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/50px-Commons-emblem-issue.svg.png 2x'
data-le-width='48' data-le-height='48' /></a> + <a href='//commons.wikimedia.org/wiki/File:Question_book.svg' class='image'><img
alt='Question book.svg' src='//upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/25px-Question_book.svg.png'
width='25' height='20' srcset='//upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/38px-Question_book.svg.
png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/50px-Question_book.svg.png 2x' data-lewidth='252' data-le-height='199' /></a> Artista original: GNOME icon artists, Jorge 2701
Archivo:Http_request_telnet_ubuntu.png Fuente: http://upload.wikimedia.org/wikipedia/commons/c/c6/Http_request_telnet_ubuntu.
png Licencia: Public domain Colaboradores: Trabajo propio Artista original: TheJosh

9.3

Content license

Creative Commons Attribution-Share Alike 3.0