Hypertext Transfer Protocol

Hypertext Transfer Protocol oHTTP (en espaol pro-tocolo de transferencia de hipertexto) es el protocolo usa-do en cada transaccin de la World Wide Web. HTTPfue desarrollado por el WorldWideWeb Consortium y laInternet Engineering Task Force, colaboracin que cul-min en 1999 con la publicacin de una serie de RFC,el ms importante de ellos es el RFC 2616 que especi-ca la versin 1.1. HTTP dene la sintaxis y la semnticaque utilizan los elementos de software de la arquitecturaweb (clientes, servidores, proxies) para comunicarse. Esun protocolo orientado a transacciones y sigue el esque-ma peticin-respuesta entre un cliente y un servidor. Alcliente que efecta la peticin (un navegador web o unspider) se lo conoce como user agent (agente del usua-rio). A la informacin transmitida se la llama recurso y sela identica mediante un localizador uniforme de recur-sos (URL). El resultado de la ejecucin de un programa,una consulta a una base de datos, la traduccin automti-ca de un documento, etc.HTTP es un protocolo sin estado, es decir, que no guar-da ninguna informacin sobre conexiones anteriores. Eldesarrollo de aplicaciones web necesita frecuentementemantener estado. Para esto se usan las cookies, que es in-formacin que un servidor puede almacenar en el sistemacliente. Esto le permite a las aplicaciones web instituir lanocin de sesin, y tambin permite rastrear usuarios yaque las cookies pueden guardarse en el cliente por tiempoindeterminado.

1 Transacciones HTTPUna transaccin HTTP est formada por un encabezadoseguido, opcionalmente, por una lnea en blanco y algndato. El encabezado especicar cosas como la accinrequerida del servidor, o el tipo de dato retornado, o elcdigo de estado.El uso de campos de encabezados enviados en las transac-ciones HTTP le dan gran exibilidad al protocolo. Estoscampos permiten que se enve informacin descriptiva enla transaccin, permitiendo as la autenticacin, cifrado eidenticacin de usuario.Un encabezado es un bloque de datos que precede a la in-formacin propiamente dicha, por lo quemuchas veces sehace referencia a l como metadato porque tiene datossobre los datos.Si se reciben lneas de encabezado del cliente, el servidorlas coloca en las variables de entorno de CGI con el pre-

jo HTTP_ seguido del nombre del encabezado. Cualquiercarcter guion ( - ) del nombre del encabezado se convier-te a caracteres "_.El servidor puede excluir cualquier encabezado queya est procesado, como Authorization, Content-type yContent-length. El servidor puede elegir excluir alguno otodos los encabezados, si incluirlos, si se excede algnlmite del entorno de sistema. Ejemplos de esto son lasvariables HTTP_ACCEPT y HTTP_USER_AGENT.

HTTP_ACCEPT. Los tipos MIME que el clienteaceptar, dados los encabezados HTTP. Otros pro-tocolos quizs necesiten obtener esta informacin deotro lugar. Los elementos de esta lista deben estarseparados por una coma, como se dice en la especi-cacin HTTP: tipo, tipo.

HTTP_USER_AGENT. El navegador que utilizael cliente para realizar la peticin. El formato gene-ral para esta variable es: software/versin bibliote-ca/versin.

El servidor enva al cliente:

Un cdigo de estado que indica si la peticin fue co-rrecta o no. Los cdigos de error tpicos indican queel archivo solicitado no se encontr, que la peticinno se realiz de forma correcta o que se requiere au-tenticacin para acceder al archivo.

La informacin propiamente dicha. Como HTTPpermite enviar documentos de todo tipo y formato,es ideal para transmitir multimedia, como grcos,audio y video. Esta libertad es una de las mayoresventajas de HTTP.

Informacin sobre el objeto que se retorna.

Hay que tener en cuenta que la lista no es una lista com-pleta de los campos de encabezado y que todos ellos slotienen sentido en una direccin.

2 VersionesHTTP 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 versinde HTTP. El cliente le dice al servidor al principio de lapeticin la versin que usa, y el servidor usa la misma ouna anterior en su respuesta.

1

2 4 MTODOS DE PETICIN

0.9 Obsoleta. Soporta slo un comando, GET, y ademsno especica el nmero de versin HTTP. No sopor-ta cabeceras. Como esta versin no soporta POST,el cliente no puede enviarle mucha informacin alservidor.

HTTP/1.0 (mayo de 1996) Esta es la primera revisindel protocolo que especica su versin en las comu-nicaciones, y todava se usa ampliamente, sobre to-do en servidores proxy.

HTTP/1.1 (junio de 1999)[1][2]

Versin actual; las conexiones persistentes es-tn activadas por defecto y funcionan bien conlos proxies. Tambin permite al cliente enviarmltiples peticiones a la vez por la misma co-nexin (pipelining) lo que hace posible elimi-nar el tiempo de Round-Trip delay por cada pe-ticin.

HTTP/1.2 Los primeros borradores de 1995 del docu-mento PEP an Extension Mechanism for HTTP(el cul propone el Protocolo de Extensin de Pro-tocolo, abreviado PEP) los hizo el World WideWebConsortium y se envi al Internet Engineering TaskForce. El PEP inicialmente estaba destinado a con-vertirse en un rango distintivo de HTTP/1.2.[3] Enborradores posteriores, sin embargo, se elimin lareferencia a HTTP/1.2. El RFC 2774 (experimen-tal), HTTP Extension Framework, incluye en granmedida a PEP. Se public en febrero de 2000.

3 Ejemplo de un dilogo HTTPPara obtener un recurso con el URL http://www.example.com/index.html

1. Se abre una conexin al host www.example.com,puerto 80 que es el puerto por defecto para HTTP.

2. Se enva un mensaje en el estilo siguiente:

GET /index.html HTTP/1.1 Host: www.example.comUser-Agent: nombre-cliente [Lnea en blanco]La respuesta del servidor est formada por encabezadosseguidos del recurso solicitado, en el caso de una pginaweb:HTTP/1.1 200 OK Date: Fri, 31 Dec 2003 23:59:59GMT Content-Type: text/html Content-Length: 1221 Pgina principal de tuHost(Contenido) . . .

4 Mtodos de peticinHTTP dene 8 mtodos (algunas veces referido comoverbos) que indica la accin que desea que se efecte

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

sobre el recurso identicado. Lo que este recurso repre-senta, si los datos pre-existentes o datos que se generan deforma dinmica, depende de la aplicacin del servidor. Amenudo, el recurso corresponde a un archivo o la salidade un ejecutable que residen en el servidor.

HEAD Pide una respuesta idntica a la que correspon-dera a una peticin GET, pero sin el cuerpo de larespuesta. Esto es til para la recuperacin de meta-informacin escrita en los encabezados de respuesta,sin tener que transportar todo el contenido.

GET Pide una representacin del recurso especicado.Por seguridad no debera ser usado por aplicacionesque causen efectos ya que transmite informacin atravs de la URI agregando parmetros a la URL.La peticin puede ser simple, es decir en una lineao compuesta de la manera que muestra el ejemplo.

Ejemplo:GET /images/logo.png HTTP/1.1 obtiene un recurso

llamado logo.pngEjemplo con parmetros:/index.php?page=main&lang=es

POST Enva los datos para que sean procesados por elrecurso identicado. Los datos se incluirn en elcuerpo de la peticin. Esto puede resultar en la crea-cin de un nuevo recurso o de las actualizaciones delos recursos existentes o ambas cosas.

PUT Sube, carga o realiza un upload de un recurso es-pecicado (archivo), es el camino ms eciente parasubir archivos a un servidor, esto es porque en POSTutiliza un mensaje multiparte y el mensaje es de-codicado por el servidor. En contraste, el mtodoPUT te permite escribir un archivo en una conexinsocket establecida con el servidor.

3La desventaja del mtodo PUT es que los servidores dehosting 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 devuelta en un mensaje de respuesta, en la seccin delcuerpo de entidad, toda la data que reciba del men-saje de solicitud. Se utiliza con nes de comproba-cin y diagnstico.

OPTIONS Devuelve los mtodos HTTP que el servidorsoporta para un URL especco. Esto puede ser uti-lizado para comprobar la funcionalidad de un ser-vidor web mediante peticin en lugar de un recursoespecco.

CONNECT Se utiliza para saber si se tiene acceso a unhost, no necesariamente la peticin llega al servidor,este mtodo se utiliza principalmente para saber siun proxy nos da acceso a un host bajo condicionesespeciales, como por ejemplo corrientes de datosbidireccionales encriptadas (como lo requiere SSL).

5 Cdigos de respuesta 1xx Mensajes

2xx Operacin exitosa

3xx Redireccin

4xx Error por parte del cliente

5xx Error del servidor

6 Vase tambin Transport Layer Security HTTPS HTTP Strict Transport Security

7 Referencias[1] Enero de 1997. Se publica la primera versin de la espe-

cicacin HTTP/1.1

[2] Junio de 1999. Publicada la ltima versin de la especi-cacin HTTP/1.1

[3] PEP: An Extension Mechanism for HTTP. Cita: For ex-perimental purposes, PEP-compatibility is equated withHTTP/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 URLOnline

4 9 TEXTO E IMGENES DE ORIGEN, COLABORADORES Y LICENCIAS

9 Texto e imgenes de origen, colaboradores y licencias9.1 Texto

Hypertext Transfer Protocol Fuente: http://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol?oldid=83236711 Colaboradores:Astro-Nomo, Andre Engels, Maveric149, Iranzop, Macar~eswiki, Nnss, Moriel, Sauron, JorgeGG, Agomez, Angus, Sanbec, Dodo, Triku, Ascn-der, 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~eswiki, Orgullobot~eswiki,RobotQuistnix, Platonides, Superzerocool, Yrbot, Oscar ., FlaBot, Vitamine, YurikBot, Mortadelo2005, GermanX, KnightRider, The Pho-tographer, Eloy, JRGL, Eskimbot, Gnovaro, Maldoror, Grizzly Sigma, Alcojol, Er Komandante, Cheveri, Tomatejc, Jcarlos77, Siabef,BOTpolicia, CEM-bot, Baiji, Antur, Mcetina, Escarlati, FrancoGG, Thijs!bot, Locovich, Isha, Egaida, Xoneca, Atardecere, Mpeinadopa,JAnDbot, Jugones55, DeathMaster, BetBot~eswiki, Muro de Aguas, TXiKiBoT, Elisardojm, Humberto, Netito777, Claudio Elias, Rei-bot,Idioma-bot, Plux, Manuel Trujillo Berges, Biasoli, Tradeos, AlnoktaBOT, Cinevoro, VolkovBot, Technopat, Queninosta, Rogeliovelas-quez, Matdrodes, Herresuelo, Shooke, Lucien leGrey, Barri, Rafael.heras, Muro Bot, Numbo3, Dinopmi, SieBot, Mushii, Ctrl Z, Ensada,Cobalttempest, CoverUp, STBot~eswiki, OboeCrack, Greek, Jmaquino, DorganBot, Tirithel, robot, Jarisleif, Carlos56, HUB, Dra-gonBot, Botelln, Leonpolanco, Pan con queso, Clouder~eswiki, Apj, Valerypipettu, Valentin estevanez navarro, SilvonenBot, Camilo,UA31, Shalbat, Vaites, AVBOT, Lohan21, David0811, Logo, Louperibot, MastiBot, Gustavo.ramos, Angel GN, MarcoAurelio, Diegus-jaimes, 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, Tara-wa1943, 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: 354

9.2 Imgenes Archivo:Commons-emblem-question_book_orange.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/1/1f/

Commons-emblem-question_book_orange.svg Licencia: CC BY-SA 3.0 Colaboradores: + Artista original: GNOME icon artists, Jorge 2701

Archivo:Http_request_telnet_ubuntu.png Fuente: https://upload.wikimedia.org/wikipedia/commons/c/c6/Http_request_telnet_ubuntu.png Licencia: Public domain Colaboradores: Trabajo propio Artista original: TheJosh

9.3 Licencia de contenido Creative Commons Attribution-Share Alike 3.0

Transacciones HTTP Versiones Ejemplo de un dilogo HTTP Mtodos de peticin Cdigos de respuesta Vase tambin Referencias Enlaces externos Texto e imgenes de origen, colaboradores y licenciasTextoImgenesLicencia de contenido