Protocolu de tresferencia d'hipertestu

Protocolu de tresferencia d'hipertestu

Familia:	Familia de protocolos d'Internet
Función:	Tresferencia de hipertestu
Cabera versión:	{{{Cabera_versión}}}
Puertos:	80/TCP
Allugamientu na pila de protocolos Aplicación HTTP Tresporte TCP Rede IP
Estándares:	RFC 1945 (HTTP/1.0, 1996) RFC 2616 (HTTP/1.1, 1999) RFC 2774 (HTTP/1.2, 2000) RFC 7540 (HTTP/2, 2015)

El Protocolu de tresferencia de hipertestu (n'inglés: Hypertext Transfer Protocol o HTTP) ye'l protocolu de comunicaciones que dexa les tresferencies d'información na World Wide Web. HTTP foi desenvueltu pol World Wide Web Consortium y la Internet Engineering Task Force, collaboración que remató en 1999 cola publicación d'una serie de RFC, el más importante d'ellos ye'l RFC 2616 qu'especifica la versión 1.1. HTTP define la sintaxis y la semántica qu'utilicen los elementos de software de l'arquiteutura web (veceres, servidores, proxies) pa comunicase. HTTP ye un protocolu ensin estáu, esto ye, nun guarda nenguna información sobre conexones anteriores. El desenvolvimientu d'aplicaciones web precisa frecuentemente caltener estáu. Pa esto usen les cookies, que ye información qu'un servidor puede almacenar nel sistema veceru. Esto déxa-y a les aplicaciones web instituyir la noción de sesión, y tamién dexa rastrexar usuarios una y bones les cookies pueden guardase nel veceru por tiempu indetermináu.

Versiones

HTTP pasó por múltiples versiones del protocolu, munches de les cuales son compatibles coles anteriores. El RFC 2145 describe l'usu de los númberos de versión d'HTTP. El veceru diz-y al servidor de primeres del pidimientu la versión qu'usa, y el servidor usa la mesma o una anterior na so respuesta.

0.9 (llanzada en 1991)

Obsoleta. Soporta namái un comandu, GET, y amás nun especifica'l númberu de versión HTTP. Nun soporta cabeceres. Como esta versión nun soporta POST, el veceru nun puede unvia-y muncha información al servidor.

HTTP/1.0 (mayu de 1996)

Esta ye la primer revisión del protocolu qu'especifica la so versión nes comunicaciones, ya inda s'usa llargamente, sobremanera en servidores proxy. Dexa los métodos de pidimientu GET, HEAD y POST.

HTTP/1.1 (xunu de 1999)

Versión más usada anguaño; Les conexones persistentes tán activaes por defectu y funcionen bien colos proxies. Tamién dexa al veceru unviar múltiples pidimientos al empar pola mesma conexón (pipelining) lo que fai posible esaniciar el tiempu de Round-Trip delay per cada pidimientu.

HTTP/1.2 (febreru de 2000)

Los primeros borradores de 1995 del documentu PEP — an Extension Mechanism for HTTP (el cuál propón el Protocolu d'Estensión de Protocolu, embrivíu PEP) facer el World Wide Web Consortium y unvióse al Internet Engineering Task Force. El PEP primeramente taba destináu a convertise nun rangu distintivu d'HTTP/1.2. En borradores posteriores, sicasí, esanicióse la referencia a HTTP/1.2. El RFC 2774 (esperimental), HTTP Extension Framework, inclúi en gran midida a PEP. Publicar en febreru de 2000.

HTTP/2 (mayu de 2015)

Artículu principal: HTTP/2

Nel añu 2012 apaecen los primeros borradores de la nueva versión d'HTTP (HTTP/2). Esta nueva versión nun modificar la semántica d'aplicación de http (tolos conceutos básicos siguen ensin cambeos). Les sos meyores enfocar en como se empaquetan los datos y nel tresporte. Por casu, añade l'usu d'una única conexón, la compresión de cabeceres o'l serviciu 'server push'. Los esploradores más importantes solo soporten HTTP 2.0 sobre TLS usando la estensión ALPNque rique TLSv1.2 o cimeru.

Descripción

Ye un protocolu empobináu a transaiciones y sigue l'esquema pidimientu-respuesta ente un veceru y un servidor. El veceru (suélse-y llamar "axente d'usuariu", n'inglés user agent) realiza un pidimientu unviando un mensaxe, con ciertu formatu al servidor. El servidor (suélse-y llamar un servidor web) únvia-y un mensaxe de respuesta. Exemplos de veceru son los navegador web y les gatuñes web (tamién conocíes pol so términu inglés, webcrawlers).

Mensaxes

Los mensaxes HTTP, son en testu planu lo que lo fai más legible y bono de depurar. Esto tien l'inconveniente de faer los mensaxes más llargos.

Los mensaxes tienen la siguiente estructura:

• Llinia inicial (termina con torna de carru y un saltu de llinia) con
  • Para los pidimientos: l'aición riquida pol servidor (método de pidimientu) siguíu de la URL del recursu y la versión HTTP que soporta'l veceru.
  • Pa respuestes: La versión del HTTP usáu siguíu del código de respuesta (qu'indica que pasó col pidimientu siguíu de la URL del recursu) y de la frase acomuñada a dichu retorno.
• Les cabeceres del mensaxe que terminen con una llinia en blancu. Son metadatos. Estes cabeceres danlu gran flexibilidá al protocolu.
• Cuerpu del mensaxe. Ye opcional. La so presencia depende de la llinia anterior del mensaxe y del tipu de recursu al que fai referencia la URL. Típicamente tien los datos que s'intercambien veceru y servidor. Por casu pa un pidimientu podría contener ciertos datos que quieren unviase al servidor por que los procese. Pa una respuesta podría incluyir los datos que'l veceru solicitó.

Métodos de pidimientu

Un pidíu HTTP usando telnet. El pidíu (request), cabeceres de respuesta (response headers) y el cuerpu de la respuesta (response body) tán resaltaos.

HTTP define una serie predefinida de métodos de pidimientu (delles vegaes referíu como "verbos") que pueden utilizase. El protocolu tien flexibilidá pa dir añadiendo nuevos métodos y p'asina añader nueves funcionalidades. El númberu de métodos de pidimientu fuéronse aumentando según avanzábense nes versiones. Cada métodu indica l'aición que desea que s'efectúe sobre'l recursu identificáu. Lo qu'esti recursu representa depende de l'aplicación del servidor. Por casu el recursu puede correspondese con un archivu que mora nel servidor.

HEAD

RFC 2616. Pide una respuesta idéntica a la que correspondería a un pidimientu GET, pero na respuesta nun se devuelve'l cuerpu. Esto ye útil pa poder recuperar los metadatos de les encabezadures de respuesta, ensin tener que tresportar tol conteníu.

GET

RFC 2616. Pide una representación del recursu especificáu. Por seguridá nun debería ser usáu por aplicaciones que causen efeutos yá que tresmite información al traviés de la URI amestando parámetros a la URL. El pidimientu puede ser simple, ye dicir nuna llinia o compuesta de la manera qu'amuesa l'exemplu. Exemplu:

GET /images/logo.png HTTP/1.1 llogra un recursu llamáu logo.png

Exemplu con parámetros:

/index.php?page=main&lang=es

POST

RFC 2616. Unvia los datos por que sían procesaos pol recursu identificáu. Los datos van incluyir nel cuerpu del pidimientu. Esto puede resultar na creación d'un nuevu recursu o de les actualizaciones de los recursos esistentes o dambes coses.

PUT

RFC 2616. Xube, carga o realiza un upload d'un recursu especificáu (archivu), ye'l camín más eficiente pa xubir archivos a un servidor, esto ye porque en POST utiliza un mensaxe multiparte y el mensaxe ye decodificado pol servidor. En contraste, el métodu PUT te dexa escribir un archivu nuna conexón socket establecida col servidor. La desventaxa del métodu PUT ye que los servidores de hosting compartíu nun lo tienen habilitáu. Exemplu:

PUT /path/filename.html HTTP/1.1

DELETE

RFC 2616. Borra'l recursu especificáu.

TRACE

RFC 2616. Esti métodu solicita al servidor que na respuesta meta tolos datos que reciba nel mensaxe de pidimientu. Utilizar con fines de depuración y diagnósticu yá que el veceru puede ver lo que llega al servidor y de esta forma ver lo qu'añaden al mensaxe'l servidores entemedios

OPTIONS

RFC 2616. Devuelve los métodos HTTP que'l servidor soporta pa una URL específicu. Esto pue ser utilizáu pa comprobar la funcionalidad d'un servidor web por aciu pidimientu en llugar d'un recursu específicu.

CONNECT

RFC 2616. Utilizar pa saber si tiense accesu a un host, non necesariamente'l pidimientu llega al servidor, esti métodu utilízase principalmente pa saber si un proxy danos accesu a un host so condiciones especiales, como por casu "corrientes" de datos bidireccionales encriptaes (como lo riquir SSL).

PATCH

La so función ye la mesma que PUT, Utilizar p'actualizar, pero la diferencia ye que aqui puedes escoyer parcialmente una o delles partes.

[2]

SEARCH

[3]

COPY

RFC 2518

LOCK

RFC 2323

UNLOCK

RFC 2518

MOVE

RFC 2518

MKCOL

RFC 2518

PROPFIND

RFC 2518

PROPPATCH

RFC 2518

MERGE

RFC 3253

UPDATE

RFC 3253

LABEL

RFC 3253

Códigos de respuesta

Artículu principal: Códigos de tao HTTP

El códigu de respuesta o torna ye un númberu qu'indica que pasó col pidimientu. El restu del conteníu de la respuesta va depender del valor d'esti códigu. El sistema ye flexible y de fechu la llista de códigos foi aumentando para asina afaese a los cambeos ya identificar nueves situaciones. Cada códigu tien un significáu concretu. Sicasí'l númberu de los códigos tán escoyíos de tala forma que según si pertenez a una centena o otra puédase identificar el tipu de respuesta que dio'l servidor:

• Códigos con formatu 1xx: Respuestes informatives. Indica que'l pidimientu foi recibida y tase procesando.
• Códigos con formatu 2xx: Respuestes correutes. Indica que'l pidimientu foi procesada correutamente.
• Códigos con formatu 3xx: Respuestes de redirección. Indica que'l veceru precisa realizar más aiciones pa rematar el pidimientu.
• Códigos con formatu 4xx: Errores causaos pol veceru. Indica qu'hubo un error nel procesáu del pidimientu por causa de que'l veceru fixo daqué mal.
• Códigos con formatu 5xx: Errores causaos pol servidor. Indica qu'hubo un error nel procesáu del pidimientu por causa de un fallu nel servidor.

Cabeceres

Artículu principal: Cabeceres HTTP

Son los metadatos que s'unvien nos pidimientos o respuesta HTTP p'apurrir información esencial sobre la transaición en cursu. Cada cabecera ye especificada por un nome de cabecera siguíu por dos puntos, un espaciu en blancu y el valor de dicha cabecera siguida por una torna de carru siguíu por un saltu de llinia. Úsase una llinia en blancu pa indicar el final de les cabeceres. Si nun hai cabeceres la llinia en blancu tien de permanecer.

Les cabeceres danlu gran flexibilidá al protocolu dexando añader nueves funcionalidades ensin tener que camudar la base. Por eso según fueron asocediendo les versiones d'HTTP fuéronse añadiendo más y más cabeceres dexaes.

Les cabeceres pueden tener metadatos que tienen que ser procesaos pol veceru (ej. en respuesta a pidimientu puede indicase el tipu del conteníu que contién), pol servidor (ej. tipos de representaciones aceptables pol veceru del conteníu que pide) o polos intermediarios (ej. como xestionar el cachéu per parte de los proxys)

Dependiendo del tipu de mensaxe nel que puede dir una cabecera podemos clasificar en cabeceres de pidimientu, cabeceres de respuesta y cabeceres que pueden dir tantu nun pidimientu como nuna respuesta.

Podemos clasificar les cabeceres según la so función. Por casu:

• Cabeceres qu'indiquen les capacidaes aceptaes pol qu'unvia'l mensaxe: Accept (indica'l MIME aceptáu), Accept-Charset (indica'l códigu de calteres aceptáu), Accept-Encoding (indica'l métodu de compresión aceptáu), Accept-Language (indica l'idioma aceptáu), User-Agent (pa describir al veceru), Server (indica'l tipu de servidor), Allow (métodos dexaos pal recursu)
• Cabeceres que describen el conteníu: Content-Type (indica'l MIME del conteníu), Content-Length (llargor del mensaxe), Content-Range, Content-Encoding, Content-Language, Content-Location.
• Cabeceres que faen referencies a URIs: Location (indica onde ta'l conteníu), Referer (Indica l'orixe del pidimientu).
• Cabeceres que dexen aforrar tresmisiones: Date (fecha de creación), If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, If-Range, Expires, Last-Modified, Cache-Control, Via, Pragma, Etag, Age, Retry-After.
• Cabeceres pa control de cookies: Set-Cookie, Cookie
• Cabeceres pa autentificación: Authorization, WW-Authenticate
• Cabeceres pa describir la comunicación: Host (indica máquina destino del mensaxe), Connection (indica como establecer la conexón)
• Otres: Range (pa descargar namái partes del recursu), Max-Forward (llende de cabeceres añadíes en TRACE).

Exemplu de diálogu HTTP

Pa llograr un recursu col URL http://www.example.com/index.html

1. Ábrese una conexón nel puertu 80 del host www.example.com .El puertu 80 ye'l puertu predefinido para HTTP. Si quixera utilizase el puertu XXXX habría que codificarlo na URL de la forma http://www.example.com:XXXX/index.html
2. Únviase un mensaxe nel estilu siguiente:

 GET /index.html HTTP/1.1
 Host: www.example.com
 Referer: www.google.com
 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
 Connection: keep-alive
 [Llinia en blancu]

La respuesta del servidor ta formada por encabezadures siguíes del recursu solicitáu, nel casu d'una páxina web:

HTTP/1.1 200 OK
Date: Fri, 31 Dec 2003 23:59:59 GMT
Content-Type: text/html
Content-Length: 1221

<html lang="eo">
<head>
<meta charset="utf-8">
<title>Títulu del sitiu</title>
</head>
<body>
<h1>Páxina principal de tuHost</h1>
(Conteníu)
 .
 .
 .
</body>
</html>

Ver tamién

• Transport Layer Security
• HTTPS
• HTTP Strict Transport Security
• HTTP (P2P)
• HTTP/2

Enllaces esternos

• RFC-2616
• HTTP - Hypertext Transfer Protocol. W3C
• HTTP Made Really Easy. byJames Marshall, 1997
• Validación d'HTTP Headers Archiváu 2019-08-28 en Wayback Machine Verificación d'URL Online
• Prueba de compatibilidá HTTP/2

• Datos: Q8777
• Multimedia: Hypertext Transfer Protocol