|
Protocol de transferència d'hipertext
HistòriaEl 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. FuncionamentHTTP 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. Missatge de peticióEl missatge de petició està format per:
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 de petició[6] 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.
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. Idempotència i nullpotència[8]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.
HTTP Status CodesLa 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:
VersionsHTTP 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.
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] Referències
Vegeu també A Wikimedia Commons hi ha contingut multimèdia relatiu a: Protocol de transferència d'hipertext |
