Protocol de transferència d'hipertext

De Viquipèdia
Dreceres ràpides: navegació, cerca
El model TCP/IP
Capa Protocol
Aplicació HTTP  · FTP  · TFTP  · SMTP  · POP3  · IMAP  · DNS  · IRC  · SSH  · Telnet  · TLS i SSL  · NFS  · NNTP  · NTP  · SMB/CIFS  · SNMP  · Gopher  · RTP  · RTCP  · SOAP  · SIP
Transport TCP  · UDP  · SCTP  · SPX  · NetBIOS
Xarxa IP (IPv4  · IPv5  · IPv6)  · ICMP  · IGMP  · AppleTalk  · IPX  · NetBEUI  · X.25
Enllaç de dades ARP  · RARP  · ATM  · DSL  · Ethernet  · Frame Relay  · HDLC  · NDP  · PPP  · SLIP  · Token Ring  · Wi-Fi
Física Cable coaxial  · Cable de fibra òptica  · Cable de parells trenats  · Microones  · Ràdio  · RS-232  · RS-485
Categoria:Xarxes informàtiques

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.

Historia[modifica | modifica el codi]

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 rapida 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 | modifica el codi]

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 (Universal Resource Identifier), com a lloc mitjançant URL (Universal Resource Locator) o com a nom mitjançant URN (Universal 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 | modifica el codi]

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 | modifica el codi]

Petició HTTP usant telnet. La petició, les capçaleres de la resposta i el cos de la respost hi són marcats.

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ó destijada 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 una URL afecta únicament a aquella 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 | modifica el codi]

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 a 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
PUT No
DELETE Sí(amb matisos) No
POST No No

HTTP Status Codes[5][modifica | modifica el codi]

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 sintaxis.
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ó.

Vegeu també[modifica | modifica el codi]

Referències[modifica | modifica el codi]

A Wikimedia Commons hi ha contingut multimèdia relatiu a: Protocol de transferència d'hipertext Modifica l'enllaç a Wikidata
  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
  5. HTTP Status Code Registry, Internet Assigned Numbers Authority