Protocol de transferència d'hipertext

El protocol de transferència d'hipertext (en inglés: Hypertext Transfer Protocol, abreviat HTTP) és el protocol de comunicació que permet les transferències d'informació a través d'archius (XML, HTML…) en la World Wide Web. Va ser desenrollat pel World Wide Web Consortium i l'Internet Engineering Task Force, colaboració que va culminar en 1999 en la publicació d'una série de RFC, sent el més important d'ells el RFC 2616 que especifica la versió 1.1. HTTP definix la sintaxis i la semàntica que utilisen els elements de software de l'arquitectura web (clients, servidors, proxies) per a comunicar-se.

HTTP és un protocol sense estat, per lo que no guarda cap informació sobre conexions anteriors. El desenrolle d'aplicacions web necessita freqüentment mantindre estat. Per a açò s'usen les cookies, que és informació que un servidor pot almagasenar en el sistema client. Açò li permet a les aplicacions web instituir la noció de sessió, i també permet rastrejar usuaris, ya que les cookies poden guardar-se en el client per temps indeterminat.

Descripció

És un protocol orientat a transaccions i seguix l'esquema petició-resposta entre un client i un servidor. El client (se li sol cridar "agent d'usuari", de l'anglés user agent) realisa una petició enviant un mensage, en cert format al servidor. El servidor (al que és comú cridar-li servidor web) li envia un mensage de resposta. Eixemples de client són els navegadors web i les arrapes web (també conegudes pel seu terme anglés, webcrawlers).

Mensages

Els mensages HTTP són en text pla, lo que ho fa més llegible i fàcil de depurar. No obstant, açò té l'inconvenient de fer els mensages més llarcs. Els mensages tenen la següent estructura:

• Llínea inicial (termina en tornada de carro i un bot de llínea) en
  • Per a les peticions: l'acció requerida pel servidor (método de petició) seguit de l'URL del recurs i la versió d'HTTP que soporta el client.
  • Per a respostes: la versió de l'HTTP usat seguit del còdic de resposta (que indica qué ha passat en la petició seguit de l'URL del recurs) i de la frase associada a dit tornada.
• Les capçaleres del mensage que terminen en una llínea en blanc. Són metadatos. Estes capçaleres li donen gran flexibilitat al protocol.
• Cos del mensage. És opcional. La seua presència depén de la llínea anterior del mensage i del tipo de recurs al que fa referència l'URL. Típicament té les senyes que s'intercanvien client i servidor. Per eixemple, per a una petició podria contindre certes senyes que es volen enviar al servidor per a que els processe. Per a una resposta podria incloure les senyes que el client ha solicitat.

Métodos de petició

Un pedido HTTP usando telnet. La petició (request), capçaleres de resposta (response headers) i el cos de la resposta (response body) estan resaltats.

HTTP definix una série predefinida de métodos de petició (algunes voltes denominats "verps", encara que este terme no està present en les especificacions) per a indicar l'acció que es desija realisar sobre el recurs identificat. Que este recurs siga preexistente (senyes ya almagasenades) o es genere de forma dinàmica depén de l'implementació del servidor. A sovint, el recurs correspon a un archiu o a l'eixida d'un eixecutable que residix en el servidor.

L'especificació d'HTTP/1.0 definix els métodos GET, HEAD i POST i enumera els métodos PUT, DELETE, LINK I UNLINK en una secció de métodos adicionals. No obstant, l'especificació HTTP/1.1 definix formalment i afig cinc métodos nous: PUT, DELETE, CONNECT, OPTIONS i TRACE. Qualsevol client pot utilisar qualsevol método i el servidor es pot configurar per a donar soport a qualsevol combinació de métodos. En cas que un método siga desconegut per a un intermediari, ho tractarà com un método insegur i no idempotent. No hi ha llímit per al número de métodos que es poden definir, lo que permet que es puguen especificar nous métodos sense afectar l'infraestructura anterior. Per eixemple, WebDAV va definir sèt métodos nous i el RFC 5789 va especificar el método PATCH.

Els noms dels métodos són sensibles a mayúscules. Açò contrasta en els noms dels camps de les capçaleres HTTP, que no són sensibles a mayúscules.

Definicions

1. Un método de petició és segur si una petició en eixe método no té un efecte intencional en el servidor. En atres paraules, un método és segur si és de solament llectura. No obstant, un método segur pot tindre efectes secundaris que el client no pot vore, com afegir informació de la petició a un archiu de registre o realisar un cobro a un conte de publicitat.
2. Un método és idempotent si múltiples peticions en eixe método tenen el mateix efecte que una sola petició. Els métodos segurs són trivialmente idempotents, ya que no deurien tindre efecte algun en el servidor.
3. Un método és cacheable si es poden almagasenar les respostes per a la seua futura reutilisació.

Métodos estàndar

Tots els servidors web de propòsit general deuen implementar a lo manco els métodos GET i HEAD, mentres que el restant de métodos són opcionals.

Propietats dels métodos de petició

Método	RFC	La petició té càrrega útil	La resposta té càrrega útil	Segur	Idempotent	Cacheable
GET	Plantilla:IETF RFC	style="Lliure" |	style="Sí" |	style="Sí" |	style="Sí" |	style="Sí" |
HEAD	Plantilla:IETF RFC	style="Lliure" |	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |
POST	Plantilla:IETF RFC	style="Sí" |	style="Sí" |	style="No" |	style="No" |	style="Sí" |
PUT	Plantilla:IETF RFC	style="Sí" |	style="Sí" |	style="No" |	style="Sí" |	style="No" |
DELETE	Plantilla:IETF RFC	style="Lliure" |	style="Sí" |	style="No" |	style="Sí" |	style="No" |
CONNECT	Plantilla:IETF RFC	style="Lliure" |	style="Sí" |	style="No" |	style="No" |	style="No" |
OPTIONS	Plantilla:IETF RFC	style="Lliure" |	style="Sí" |	style="Sí" |	style="Sí" |	style="No" |
TRACE	Plantilla:IETF RFC	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |	style="No" |
PATCH	Plantilla:IETF RFC	style="Sí" |	style="Sí" |	style="No" |	style="No" |	style="No" |

GET

El método GET solicita que el recurs de destí transferixca una representació del seu estat. Les solicituts que usen GET solament deuen recuperar senyes i no deuen tindre cap atre efecte. (Açò també és cert per a alguns atres métodos HTTP.) Per a recuperar recursos sense realisar canvis, és preferible GET sobre POST, ya que es pot accedir a eixos recursos a través d'una URL. Açò permet afegir l'URL a marcadors i compartir-la i fa que les respostes GET es puguen almagasenar en caché, lo que aforra ample de banda. El W3C ha publicat principis orientadores sobre esta distinció, indicant: «El disseny d'aplicacions web deu estar informat dels principis anteriors, pero també de les llimitacions rellevants».

HEAD

El método HEAD solicita que el recurs de destí transferixca una representació del seu estat, de la mateixa manera que el método GET, pero sense les senyes de representació continguts en el cos de la resposta. Açò és útil per a poder recuperar els metadatos de les capçaleres de la resposta, sense tindre que transportar el contingut complet. Es pot usar, per eixemple, per a comprovar si una pàgina està disponible a través del còdic d'estat o per a obtindre ràpidament el tamany d'un archiu (Content-Length).

POST

El método POST solicita que el recurs de destí processe la representació continguda en la petició d'acort en la semàntica del propi recurs. A nivell semàntic està orientat a crear un nou recurs, la naturalea del qual vindrà especificada per la capçalera Content-Type. Es pot usar, per eixemple, per a publicar un mensage en un fòrum d'Internet, subscriure's a una llesta de correu o completar una compra en llínea.

PUT

Envia senyes al servidor, pero a diferència del método POST la URI de la llínea de petició no fa referència al recurs que els processarà, sino que identifica a les pròpies senyes. Una atra diferència en POST és semàntica (vore REST): mentres que POST està orientat a la creació de nous continguts, PUT està més orientat a l'actualisació dels mateixos (encara que també podria crear-els).

DELETE

Borra el recurs especificat.

TRACE

Solicita al servidor que introduïxca en la resposta totes les senyes que reba en el mensage de petició. S'utilisa en fins de depuració i diagnòstic ya que el client pot vore lo que aplega el servidor i d'esta forma vore tot lo que afigen el mensage els servidors intermijos.

OPTIONS

Torna els métodos HTTP que el servidor soporta per a un URL específic. Açò pot ser utilisat per a comprovar la funcionalitat d'un servidor web per mig de petició en lloc d'un recurs específic.

CONNECT

S'utilisa per a saber si es té accés a un host, no necessàriament la petició aplega al servidor, este método s'utilisa principalment per a saber si un proxy nos dona accés a un host baix condicions especials, com per eixemple "corrents" de senyes bidireccionals sifrades (com ho requerix SSL/TLS).

PATCH

La seua funció és la mateixa que PUT, el qual sobrescribe completament un recurs. S'utilisa per a actualisar, de manera parcial una o vàries parts. Està orientat també per a l'us en proxy.

Métodos de WebDAV

Artícul principal → WebDAV.

WebDAV afig els métodos següents:

COPY

Copia un recurs d'una URI a una atra.

MOVE

Mou un recurs d'una URI a una atra.

LOCK

Bloqueja un recurs.

UNLOCK

Desbloqueja un recurs.

MKCOL

Crea una nova colecció de recursos en l'ubicació especificada en el Request-URI.

PROPFIND

Obté les propietats d'un recurs.

PROPPATCH

Modifica les propietats d'un recurs.

Aixina mateix, el RFC 3253 (març de 2002) introduïx múltiples métodos adicionals per a gestionar el control de versions, com REPORT, MKACTIVITY, CHECKOUT i MERGE.

Métodos de SIP

Artícul principal → Protocol d'iniciació de sessió.

El protocol d'iniciació de sessió (SIP) introduïx els events SUBSCRIU i NOTIFY per a la notificació d'events, especificats en el RFC 6665 (juliol de 2012).

Còdics de resposta

Artícul principal → Anexe:Còdics d'estat HTTP.

El còdic de resposta o tornada és un número que indica que ha passat en la petició. El restant del contingut de la resposta dependrà del valor d'este còdic. El sistema és flexible, i de fet la llista de còdics ha anat aumentant para aixina adaptar-se als canvis i identificar noves situacions.

Cada còdic té un significat concret. No obstant, el número dels còdics estan elegits de tal forma que segons si pertany a una centena o una atra es puga identificar el tipo de resposta que ha donat el servidor:

Còdics en format 1xx

Respostes informatives. Indica que la petició ha segut rebuda i s'està processant.

Còdics en format 2xx

Respostes correctes. Indica que la petició ha segut processada correctament.

Còdics en format 3xx

Respostes de redirecció. Indica que el client necessita realisar més accions per a finalisar la petició.

Còdics en format 4xx

Errors causats pel client. Indica que hi ha hagut un error en el processat de la petició a causa de que el client ha fet alguna cosa mal.

Còdics en format 5xx

Errors causats pel servidor. Indica que hi ha hagut un error en el processat de la petició a causa d'un fallo en el servidor.

Capçaleres

Artícul principal → Capçaleres HTTP.

Són els metadatos que s'envien en les peticions o resposta HTTP per a proporcionar informació essencial sobre la transacció en curs. Cada capçalera és especificada per un nom de capçalera seguit per dos punts, un espai en blanc i el valor de dita capçalera seguida per una tornada de carro seguit per un bot de llínea. S'usa una llínea en blanc per a indicar el final de les capçaleres. Si no hi ha capçaleres la llínea en blanc deu permanéixer.

Les capçaleres li donen gran flexibilitat al protocol permetent afegir noves funcionalitats sense tindre que canviar la base. Per això segons han anat succeint les versions d'HTTP s'han anat afegint més i més capçaleres permeses.

Les capçaleres poden tindre metadatos que tenen que ser processats pel client (ej. en resposta a petició es pot indicar el tipo del contingut que conté), pel servidor (ej. tipos de representacions acceptables pel client del contingut que demana) o pels intermediaris (ej. com gestionar l'escorcoll per part dels proxys)

Depenent del tipo de mensage en el que pot anar una capçalera les podem classificar en capçaleres de petició, capçaleres de resposta i capçaleres que poden anar tant en una petició com en una resposta.

Podem classificar les capçaleres segons la seua funció. Per eixemple:

• Capçaleres que indiquen les capacitats acceptades pel que envia el mensage: Accept (indica el MIME acceptat), Accept-Charset (indica el còdic de caràcters acceptat), Accept-Encoding (indica el método de compressió acceptat), Accept-Language (indica l'idioma acceptat), User-Agent (per a descriure al client), Server (indica el tipo de servidor), Allow (métodos permesos per al recurs)
• Capçaleres que descriuen el contingut: Content-Type (indica el MIME del contingut), Content-Length (llongitut del mensage), Content-Range, Content-Encoding, Content-Language, Content-Location.
• Capçaleres que fan referències a URIs: Location (indica a on està el contingut), Referer (Indica l'orige de la petició).
• Capçaleres que permeten aforrar transmissions: Dona't (data de creació), If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, If-Range, Expires, Last-Modified, Cache-Control, Via, Pragma, Etag, Age, Retry-After.
• Capçaleres per a control de cookies: Set-Cookie, Cookie
• Capçaleres per a autentificació: Authorization, WW-Authenticate.
• Capçaleres per a descriure la comunicació: Host (indica màquina destine del mensage), Connection (indica com establir la conexió)
• Atres: Range (per a descarregar solament parts del recurs), Max-Forward (llímit de capçaleres afegides en TRACE).

Eixemple de diàlec HTTP

Per a obtindre un recurs en l'URL http://www. example. com/index. html

1. S'obri una conexió en el port 80 del host www. example. com. El port 80 és el port predefinit para HTTP. Si es volguera utilisar el port XXXX, caldria codificar-ho en l'URL de la forma http://www. example. com:XXXX/index. html.
2. S'envia un mensage en l'estil següent:

 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
 [Llínea en blanc]

La resposta del servidor està formada per encapçalats seguits del recurs solicitat, en el cas d'una pàgina web:

HTTP/1.1 200 OK
Dona't: 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ítul del lloc</title>
</head>
<body>
<h1>Pàgina principal de tuHost</h1>
(Contingut)
  .
  .
  .
</body>
</html>

Versions

HTTP ha passat per múltiples versions del protocol, moltes de les quals són compatibles en les anteriors. El RFC 2145 descriu l'us dels números de versió d'HTTP. El client li diu al servidor al principi de la petició la versió que usa, i el servidor usa la mateixa o una anterior en la seua resposta.

0.9 (llançada en 1991)

Obsoleta. Soporta solament un comando, GET, i ademés no especifica el número de versió HTTP. No soporta capçaleres. Com esta versió no soporta POST, el client no pot enviar-li molta informació al servidor.

HTTP/1.0 (maig de 1996)

Esta és la primera revisió del protocol que especifica la seua versió en les comunicacions, i encara s'usa àmpliament, sobretot en servidors proxy. Permet els métodos de petició GET, HEAD i POST.

HTTP/1.1 (juny de 1999)

Versió més usada actualment;^{cita requerida} Les conexions persistents estan activades per defecte i funcionen be en els proxies. També permet al client enviar múltiples peticions al mateix temps per la mateixa conexió (pipelining) lo que fa possible eliminar el temps de Round-Trip delay per cada petició.

HTTP/1.2 (febrer de 2000)

Els primers borradors de 1995 del document PEP — an Extension Mechanism for HTTP (el qual propon el Protocol d'Extensió de Protocol, abreviat PEP) els va fer el World Wide Web Consortium i es va enviar al Internet Engineering Task Force. El PEP inicialment estava destinat a convertir-se en un ranc distintiu d'HTTP/1.2. En borradors posteriors, no obstant, es va eliminar la referència a HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, inclou en gran mida a PEP. Es va publicar en febrer de 2000.

HTTP/2 (maig de 2015)

Artícul principal → HTTP/2.

En l'any 2012 apareixen els primers borradors de la nova versió d'HTTP (HTTP/2). Esta nova versió no modifica la semàntica d'aplicació d'http (tots els conceptes bàsics continuen sense canvis). Les seues millores s'enfoquen en com s'empaqueten les senyes i en el transport. Per eixemple, afig l'us d'una única conexió, la compressió de capçaleres o el servici 'server push'. Els exploradors més importants solament soporten HTTP 2.0 sobre TLS usant l'extensió ALPN que requerix TLSv1.2 o superior.

HTTP/3 (Octubre de 2018)

Artícul principal → HTTP/3.

HTTP/3 és el successor propost d'HTTP/2, que ya està en us en la web, utilisant UDP en lloc de TCP per al protocol de transport subjacent. De la mateixa manera que l'HTTP/2, no és obsolet en les versions principals anteriors del protocol. El soport per a HTTP/3 va ser agregat a Cloudflare i Google Chrome en setembre de 2019, i pot ser habilitat en les versions estables de Chrome i Firefox.

Vore també

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