Protocol de transferència d'hipertext

El protocol de transferència d'hipertext o HTTP (HyperText Transfer Protocol) estableix el protocol per a l'intercanvi de documents d'hipertext i multimèdia al web. HTTP disposa d'una variant xifrada mitjançant SSL anomenada HTTPS.

Història[modifica]

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. Amb els anys, aquest elements passarien a dir-se World Wide Web.^[1]

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, 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.

Funcionament[modifica]

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.

Missatge de petició[modifica]

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 de petició^[2][modifica]

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^[3] 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^[4][modifica]

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.

Mètode	Idempotent	Segur
GET	Sí	Sí
PUT	Sí	No
DELETE	Sí(amb matisos)	No
POST	No	No

HTTP Status Codes[modifica]

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:

Grup	Nom del grup	Codi	Text	Descripció
1xx	Informational	-	-	-
2xx	Success	200	Ok	Resposta estàndard per peticions correctes.
2xx	Success	201	Created	La petició ha estat completada creant un nou recurs.
2xx	Success	204	No Content	El servidor ha processat correctament la petició, però no retorna cap contingut.
3xx	Redirection	-	-	-
4xx	Client Error	400	Bad Request	La petició no pot ser completada degut a un error de sintaxi.
4xx	Client Error	401	Unauthorized	Similar a 403, però usat específicament quan la autentificació és necessària i ha fallat. Token incorrecte.
4xx	Client Error	403	Forbidden	La petició era legal però el servidor refusa respondre.
4xx	Client Error	404	Not Found	La petició no pot trobar el recurs sol·licitat però pot estar disponible en un futur.
4xx	Client Error	405	Method Not Allowed	Petició realitzada a una URI usant un mètode de sol·licitud no suportat per l'anomenada URI.
4xx	Client Error	408	Request Timeout	El temps d'espera màxim del servidor s'ha esgotat esperant la petició.

Referències[modifica]

Vegeu també[modifica]

A Wikimedia Commons hi ha contingut multimèdia relatiu a: Protocol de transferència d'hipertext

[W3Bio-1] Berners-Lee biography at the World Wide Web Consortium

[2] HTTP 1.1 Section 9

[3] HTTP 1.1 Section 5.1.1

[4] REST API Tutorial, idempotence

[1]

[2]

[3]

[4]