Hypertext Transfer Protocol

Hypertext Transfer Protocol

Hyper text Transfer Protocol (HTTP) Familia: Funcin: Familia de protocolos de Internet Transferencia de hipertexto

ltima versin: 1.2 Puertos: 80/TCP

Ubicacin en la pila de protocolos Aplicacin Transporte Red Estndares: HTTP TCP IP RFC 1945 (HTTP/1.0, 1996) RFC 2616 (HTTP/1.1, 1999) RFC 2774 (HTTP/1.2, 2000)

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 especifica la versin 1.1. HTTP define 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 identifica mediante un localizador uniforme de recursos (URL). Los recursos pueden ser archivos, el resultado de la ejecucin de un programa, una consulta a una base de datos, la traduccin automtica de un documento, etc. 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 informacin que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la nocin de "sesin", y tambin permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

Transacciones HTTP
Una transaccin HTTP est formada por un encabezado seguido, opcionalmente, por una lnea en blanco y algn dato. El encabezado especificar cosas como la accin requerida del servidor, o el tipo de dato retornado, o el cdigo de estado. El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se enve informacin descriptiva en la transaccin, permitiendo as la autenticacin, cifrado e identificacin 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.

Hypertext Transfer Protocol Si se reciben lneas de encabezado del cliente, el servidor las coloca en las variables de ambiente de CGI con el prefijo 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 excede algn lmite del ambiente de sistema. Ejemplos de esto son las variables HTTP_ACCEPT y HTTP_USER_AGENT. HTTP_ACCEPT. Los tipos MIME que el cliente aceptar, dado 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 lo dice la especificacin 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. El servidor enva al cliente: Un cdigo de estado que indica si la peticin fue correcta o no. Los cdigos de error tpicos indican que el archivo solicitado no se encontr, que la peticin no se realiz de forma correcta o que se requiere autenticacin para acceder al archivo. La informacin propiamente dicha. Como HTTP permite enviar documentos de todo tipo y formato, es ideal para transmitir multimedia, como grficos, audio y video. Esta libertad es una de las mayores ventajas de HTTP. Informacin sobre el objeto que se retorna. Ten en cuenta que la lista no es una lista completa de los campos de encabezado y que algunos de ellos slo tienen sentido en una direccin.

Versiones
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 peticin la versin que usa, y el servidor usa la misma o una anterior en su respuesta. 0.9 Obsoleta. Soporta slo un comando, GET, y adems no especifica 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 especifica 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 (pipelining) lo que hace posible eliminar el tiempo de Round-Trip delay por cada peticin. HTTP/1.2 Los primeros borradores de 1995 del documento PEP an Extension Mechanism for HTTP (el cul propone el Protocolo de Extensin de Protocolo, abreviado PEP) los hizo el World Wide Web Consortium y se envi al Internet Engineering Task Force. 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.

Hypertext Transfer Protocol

Ejemplo de un dilogo HTTP

Para 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.com 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 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>Pgina principal de tuHost</h1> (Contenido) . . . </body> </html>

Mtodos de peticin
HTTP define 8 mtodos (algunas veces referido como "verbos") que indica la accin que desea que se efecte sobre el recurso identificado. Lo que este recurso representa, si los datos pre-existentes o datos que se generan de forma dinmica, depende de la aplicacin 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 idntica a la que correspondera a una peticin GET, pero sin el cuerpo de la respuesta. Esto es til para la recuperacin de meta-informacin escrita en los encabezados de respuesta, sin tener que transportar todo el contenido. GET

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

Pide una representacin del recurso especificado. Por seguridad no debera ser usado por aplicaciones que causen efectos ya que transmite informacin a travs de la URI agregando parmetros a la URL. Ejemplo: GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png Ejemplo con parmetros:

Hypertext Transfer Protocol /index.php?page=main&lang=es POST Somete los datos a que sean procesados para el recurso identificado. Los datos se incluirn en el cuerpo de la peticin. Esto puede resultar en la creacin 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 ms 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 mtodo PUT te permite escribir un archivo en una conexin socket establecida con el servidor. La desventaja del mtodo 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 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 fines de comprobacin y diagnostico. OPTIONS Devuelve los mtodos HTTP que el servidor soporta para un URL especifico.Esto puede ser utilizado para comprobar la funcionalidad de un servidor web mediante peticin en lugar de un recurso especifico CONNECT

Cdigos de respuesta
1xx Mensajes
N Descripcin Conexin rechazada

100 111

2xx Operacin exitosa

N 200 Descripcin OK

201-203 Informacin no oficial 204 205 206 Sin Contenido Contenido para recargar Contenido parcial

3xx Redirecin

Hypertext Transfer Protocol

Descripcin

301 Mudado permanentemente 302 Encontrado 303 Vea otros 304 No modificado 305 Utilice un proxy 307 Redireccin temporal

4xx Error por parte del cliente

N Descripcin

400 Solicitud incorrecta 402 Pago requerido 403 Prohibido 404 No encontrado 409 Conflicto 410 Ya no disponible 412 Fall precondicin

5xx Error del servidor

N Descripcin

500 Error interno 501 No implementado 502 Pasarela incorrecta 503 Servicio nodisponible 504 Tiempo de espera de la pasarela agotado 505 Versin de HTTP no soportada

Referencias
[1] Enero de 1997. Se publica la primera versin de la especificacin HTTP/1.1 [2] Junio de 1999. Publicada la ltima versin de la especificacin HTTP/1.1 [3] (http:/ / www. w3. org/ TR/ WD-http-pep-951122. html) PEP: An Extension Mechanism for HTTP. Cita: "For experimental purposes, PEP-compatibility is equated with HTTP/1.2."

Enlaces externos
RFC-2616 (http://www.ietf.org/rfc/rfc2616.txt) HTTP - Hypertext Transfer Protocol. W3C (http://www.w3.org/Protocols/) HTTP Made Really Easy. byJames Marshall, 1997 (http://www.jmarshall.com/easy/http/) Validacin de HTTP Headers (http://www.bairestools.com) Verificacin de URL Online

Fuentes y contribuyentes del artculo

Fuentes y contribuyentes del artculo

Hypertext Transfer Protocol Fuente: http://es.wikipedia.org/w/index.php?oldid=53099393 Contribuyentes: Agomez, Airunp, Alcojol, Amerikaos, Andre Engels, Andreasmperu, Angel GN, Angus, Antur, Apj, Ascnder, AstroNomo, Atardecere, Baiji, Barcex, Biasoli, Camilo, Caos, Carlos56, Claudio Elias, Clouder, Cookie, CoverUp, Ctrl Z, David0811, Death Master, Diegusjaimes, Dinopmi, Dodo, Dreitmen, Egaida, Elisardojm, Eloy, Ensada, Er Komandante, FAR, GermanX, Gnovaro, Greek, Gustavo.ramos, HUB, Hateinblood, Herresuelo, Hildergarn, Humberto, Ikks, Iranzop, Irbian, JCCO, JRGL, Jag2k4, Jarisleif, Jcarlos77, Jesus Belinchon, Jkbw, Jmaquino, Jmcontreras, JorgeGG, Jugones55, Katherinee21 6, Kokoo, Leonpolanco, Locovich, Lohan21, Lucien leGrey, Macar, Magister Mathematicae, Maldoror, MarcoAurelio, Matdrodes, Maveric149, Mcetina, Moriel, Mortadelo2005, Mpeinadopa, Muro de Aguas, Mushii, Netito777, Niqueco, Nnss, Numbo3, Orion sae, Ortisa, Pan con queso, Periku, Platonides, PoLuX124, Rafael.heras, Rogeliovelasquez, RubiksMaster110, Sanbec, Sauron, Savh, Sergio Andres Segovia, Shooke, Siabef, Super braulio, Superzerocool, Surfaz, Taichi, Technopat, Tirithel, Toad32767, Tomatejc, Tradeoffs, Triku, Vaites, Valentin estevanez navarro, Valerypipettu, Viko, Vitamine, Vubo, Wikipedista-perfeccionista, Xoneca, 378 ediciones annimas

Fuentes de imagen, Licencias y contribuyentes

Archivo:Http request telnet ubuntu.png Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Http_request_telnet_ubuntu.png Licencia: Public Domain Contribuyentes: TheJosh

Licencia
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/