Protocol de transferència d'hipertext

El 1988, Tim Berners-Lee va proposar al CERN un projecte d'hipertext global. El projecte va començar l'octubre de 1990 com a WorldWideWeb i a l'estiu de 1991 es comença a utilitzar la primera versió (V0.9) del protocol HTTP a Internet. Aquesta versió permetia utilitzar únicament la funció GET, és a dir, sol·licitar una pàgina web a un servidor. El projecte va incloure també el disseny del llenguatge de programació html, les tecnologies associades als servidors web i un navegador web. El primer servidor web es va posar en funcionament el 1990.^[1][2] La resposta del servidor sempre va ser una pàgina HTML.^[3] Amb els anys, aquest elements passarien a dir-se World Wide Web.^[4]

Els propers anys són destinats a la millora del protocol junt amb la resta dels elements del projecte. El 1996 es presenta oficialment la primera versió, HTTP V1.0, presentat al RFC1945 que permetia les funcions GET,^[5] HEAD i POST.

Prèviament a la presentació del HTTP V1.0, el 1995, Dave Ragget liderava un grup de treball per desenvolupar el HTTP WG amb l'objectiu d'ampliar el protocol amb més operacions, metadades i lligat a un protocol de seguretat. El gener de 1997 es publica el RFC2068 que correspon al HTTP V1.1 (HTTP WG) que amplia les prestacions del HTTP V1.0 incorporant les funcions PUT, DELETE, TRACE i OPTIONS, els codis de resposta o codis d'estat del HTTP, autentificació, la utilització de memòria cau, definicions de metadades a la capçalera i consideracions de seguretat.

Gràcies al suport rebut per part del navegadors web com Arena, Netscape, Netscape Navigato Gold, Mosaic, Lynx i Internet Explorer van permetre una ràpida adopció del protocol a tots els usuaris d'internet.

El juny del 1999 es publica la darrera actualització del protocol HTTP V1.1 en el RFC2616 que inclou la funció CONNECT com a millora més important.

HTTP segueix un model client-servidor on el client (generalment un navegador) inicia la petició d'informació establint una connexió TCP/IP al port 80 d'una màquina remota. El servidor espera una petició (consulta o request) amb el mètode i la versió del protocol utilitzat: p. ex. "GET / HTTP/1.2". A continuació, mitjançant una semàntica específica, s'envien una sèrie de capçaleres amb extensions MIME que donen metainformació sobre el tipus de document multimèdia demanat, estat de connexió, etc. a un recurs d'Internet, la referència al qual es fa mitjançant les URI (Uniform Resource Identifier), com a lloc mitjançant URL (Uniform Resource Locator) o com a nom mitjançant URN (Uniform Resource Name).

La resposta del servidor és un Acknowledge seguit del fitxer demanat, un missatge d'error, etc. El mètode GET és el més comú i permet fer lectures de pàgines, però també existeixen POST, PUT, etc.

La connexió establerta és tancada en finalitzar la transferència i la informació no és emmagatzemada enlloc. Aquesta característica ha fet proliferar l'ús de Cookies com a sistema per guardar paquets d'informació útils sobre cada usuari i així fer possible que el servidor el reconegui quan torni a fer-li una consulta.

El missatge de petició està format per:

• Línia de petició, com GET /images/logo.gif HTTP/1.1, que sol·licita un recurs anomenat /images/logo.gif al servidor
• Capçaleres, com ara Accept-Language: ca
• Una línia en blanc
• El cos del missatge (opcional)

La línia de petició i les capçaleres han d'acabar totes amb <CR><LF> (és a dir, Carriage Return (retorn de carro) seguit per un Line Feed). La línia en blanc només ha de ser <CR><LF>, sense cap espai. En el protocol HTTP/1.1 totes les capçaleres, excepte Host, són opcionals.

Una línia de petició que només contingui la ruta del fitxer és acceptada pels servidors per tal de mantenir la compatibilitat amb els clients HTTP anteriors a l'especificació HTTP/1.0.

Mètodes segons l'especificació RFC 2616 que correspon a HTTP/1.1.

L'HTTP defineix vuit maneres (a vegades anomenats "verbs") d'indicar l'acció desitjada que s'ha de dur a terme sobre el recurs. El que el recurs representa depèn de la implementació de cada servidor. Normalment però, aquest recurs és el contingut d'un fitxer, o la sortida d'un executable resident al servidor.

HEAD

Sol·licita una resposta, idèntica a la que es generaria amb una consulta GET, però sense el cos de la resposta. Aquesta comanda és útil per aconseguir les meta-dades incloses en la capçalera de la resposta, sense haver-se d'enviar tot el contingut.

GET

Sol·licita una representació del recurs especificat. Noti's que GET no s'ha d'usar per operacions que tinguin efectes col·laterals, com ara accions sobre aplicacions web. La raó d'aquesta restricció és que molts robots o web crawlers fan servir GET arbitràriament, sense tenir en compte els efectes col·laterals que les seves peticions poden causar.

POST

Envia dades per a ser processades (p. ex, en un formulari HTML) a un recurs específic. Les dades s'inclouen en el cos de la petició. Això pot implicar la creació d'un nou recurs o l'actualització d'aquest si ja existeix (o ambdós).

PUT

Apuja una representació del recurs especificat.

DELETE

Esborra el recurs especificat.

TRACE

Retorna la consulta rebuda, perquè el client pugui veure quines coses estan afegint o canviant els servidors intermedis.

OPTIONS

Retorna els mètodes HTTP que el servidor suporta per a una URL determinada. Es pot fer servir per esbrinar la funcionalitat del servidor web indicant '*' en lloc d'un recurs específic.

CONNECT

Converteix la connexió de petició en un túnel TCP/IP transparent, normalment per facilitar comunicacions xifrades amb SSL (HTTPS) a través d'un proxy HTTP no xifrat.

Els servidors han d'implementar com a mínim els mètodes GET i HEAD^[7] i, quan sigui possible, també el mètode OPTIONS.

PUT i POST poden usar-se tant per actualitzar com per crear recursos. No obstant, les seves descripcions estàndard deixen clar que no s'apliquen en el mateix context. En definitiva, mentre que una petició PUT a un URL afecta únicament aquell URL, una petició POST pot tenir qualsevol efecte. Per exemple, -en termes REST-, si el recurs a actualitzar o crear és un usuari i a més coneixem el seu identificador, hauríem d'usar el mètode PUT. Però si el que volem és crear un usuari nou sense conèixer prèviament el seu identificador, llavors hauríem d'usar el mètode POST.

Una operació és idempotent quan produeix el mateix resultat sigui quina sigui la seva execució. Fer múltiples peticions idèntiques per part del client té el mateix efecte que fer-ne sols una. Les operacions idempotents produeixen el mateix resultat al servidor, però la resposta que obté el client no té per què ser la mateixa.

PUT i POST també són diferents davant aquestes dues propietats, consideram PUT com idempotent, però no així POST: Usar el mètode PUT sobre un recurs amb un identificador determinat, sempre tindrà com a resultat el recurs existent al que correspon aquell identificador. Si ja existia s'actualitzarà i si no es crearà. En canvi, usar el mètode POST sobre un recurs sense conèixer l'identificador tindrà un resultat diferent a cada petició: la creació d'un nou usuari assignant-li un nou identificador. Quant al mètode GET, aquest sí és idempotent. Pot llegir un recurs múltiples vegades obtenint el mateix resultat, motiu pel qual mai hauria de ser usat per modificar dades. Finalment, el mètode DELETE és idempotent d'acord amb l'especificació de HTTP. Ara bé, no sempre serà així, ja que si s'esborra satisfactòriament un recurs per primer cop, el segon cop que es tracti d'esborrar el mateix recurs es podria obtenir un codi de resposta 404, que significaria l'intent per esborrar un recurs que ja no existeix.

Els 'mètodes segurs' o 'nullpotents' són aquells mètodes que no produeixen cap efecte. Per exemple, el mètode GET és segur, ja que sols retorna la representació d'un recurs, però no el modifica en cap manera. Mètodes com PUT, DELETE i POST poden canviar l'estat dels recursos, ergo no són mètodes segurs. Que un mètode sigui idempotent és una condició necessària però no suficient perquè sigui un mètode segur.

La primera línia d'una resposta HTTP s'anomena 'status line'. Aquesta línia conté un codi numèric anomenat 'status code' i va acompanyat d'un petit text que descriu el codi retornat. El primer dígit de l'status code indica de quin tipus de resposta es tracta. Si un client no reconeix un status code concret, almenys pot utilitzar el primer digit per conèixer la seva família.

Els status code més importants són:

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

0.9 (llançada el 1991)

Obsoleta. Suporta només una ordre, GET, i a més no especifica el número de versió HTTP. No suporta capçaleres. Com que aquesta versió no suporta POST, el client no pot enviar molta informació al servidor.

HTTP/1.0 (maig de 1996)

Aquesta és la primera revisió del protocol que especifica la seva versió a les comunicacions, i encara s'usa àmpliament, sobretot en servidors intermediaris. Permet els mètodes de petició GET, HEAD i POST.

HTTP/1.1 (juny de 1999)^[9][10]

Versió més usada actualment; Les connexions persistents estan activades per defecte i funcionen bé amb els proxies. També permet al client enviar múltiples peticions alhora per la mateixa connexió (pipelining) el que fa possible eliminar el temps de Round-Trip delay per cada petició.

HTTP/1.2 (febrer de 2000)

Els primers esborranys de 1995 del document PEP — an Extension Mechanism for HTTP (el qual proposa el Protocol d'Extensió de Protocol, abreujat PEP) els va fer el World Wide Web Consortium i es va enviar a l'Internet Engineering Task Force. El PEP inicialment estava destinat a convertir-se en un rang distintiu de HTTP/1.2.^[11] En esborranys posteriors, però, es va eliminar la referència a HTTP/1.2. El RFC 2774 (experimental), HTTP Extension Framework, inclou en gran manera PEP. Es va publicar al febrer de 2000.

HTTP/2 (maig de 2015)

L'any 2012 apareixen els primers esborranys de la nova versió de HTTP (HTTP/2). Aquesta nova versió no modifica la semàntica d'aplicació de http (tots els conceptes bàsics continuen sense canvis). Les seves millores s'enfoquen com s'empaqueten les dades i el transport. Per exemple, afegeix l'ús d'una única connexió, la compressió de capçaleres o el servei 'server push'. Els exploradors més importants només suporten HTTP 2.0 sobre TLS usant l'extensió ALPN^[12] que requiere TLSv1.2 o superior.^[13]

HTTP/3 (Octubre de 2018)

HTTP/3 és el successor proposat de HTTP/2,^[14][15] que ja està en ús a la web, utilitzant UDP en lloc de TCP per al protocol de transport subjacent. Igual que l'HTTP/2, no és obsolet a les versions principals anteriors del protocol. El suport per a HTTP/3 es va afegir a Cloudflare i Google Chrome al setembre de 2019,^[16][17] i pot ser habilitat en les versions estables de Chrome i Firefox.^[18]