Ogni giorno vediamo scritto qualcosa come https://www.aziendeitalia.com/ nella barra del nostro browser, ma non tutti sanno cosa c'è dietro quelle prime quattro lettere (http). La sigla HTTP significa Hyper Text Transfer Protocol, ovvero protocollo di trasferimento degli ipertesti.
Il termine protocollo denota un codice condiviso tra chi trasmette un'informazione e chi la riceve. Noi esseri umani sfruttiamo i linguaggi, come ad esempio l'Italiano, per comunicare in modo efficiente. Il sistema funziona perché l'oratore e l'ascoltatore condividono un “protocollo”, che in questo caso viene detto “dizionario dei termini”. Se una terminologia operativa (ovvero basata sul modo imperativo) venisse descritta nel formato dei protocolli informatici, avremmo qualcosa del genere:
| TERMINE | SIGNIFICATO |
|---|---|
| PARLA | Ora tocca a te dire qualcosa: ti ascolto |
| ASPETTA | Non fare niente fino a nuovo ordine |
| ecc... | ecc... |
Analogamente, siccome i computer comunicano tra loro scambiando “numeri”, il protocollo HTTP definisce una tabella condivisa di significati operativi, per esempio:
| NUMERO | SIGNIFICATO |
|---|---|
| 404 | Non so dove reperire la risorsa che mi hai chiesto |
| 500 | Non posso rispondere per motivi personali |
| ecc... | ecc... |
I numeri nella tabella qui sopra sono in realtà dei codici di risposta o codici di stato, ovvero solo una parte del protocollo HTTP, ma il paragone con la lingua italiana resta valido comunque.
Una volta chiarito il significato del termine “protocollo”, la sigla HTTP diventa autoesplicativa: il protocollo HTTP è la convenzione accettata a livello mondiale allo scopo di scambiare ipertesti (che nella grande maggioranza dei casi sono pagine HTML). Si potrebbe dire che l'HTTP è il cuore di internet, o addirittura: l'invenzione del protocollo HTTP coincide con l'invenzione di internet. Infatti la prima versione ufficiale del protocollo è stata inventata da T. Berners-Lee nel 1991, anno in cui viene convenzionalmente posta anche la nascita del World Wide Web. Ciò si può capire anche leggendo la specifica del protocollo HTTP 1.0, disponibile a questo indirizzo: la descrizione del meccanismo di trasmissione delle pagine coincide (ad alto livello) con il funzionamento di internet.
La versione 1.0 dell'HTTP presentava però alcuni limiti superati con l'avvento dell'HTTP 1.1, che è quello praticamente ancora usato ad oggi, specificato dallo standard RCF2616.
La caratteristica principale del protocollo HTTP è di essere stateless, ovvero privo di stato. Ciò significa che la connessione tra client e server viene chiusa ogni volta che viene esaudita una richiesta. Facendo un paragone con la telefonia, sarebbe come se noi chiudessimo la telefonata dopo ogni coppia di domanda e risposta. In altre parole, se la telefonia fosse stateless, tra uno scambio di frasi e il successivo dovrei ogni volta “ricomporre il numero” e “telefonare di nuovo”, senza la certezza di riuscire a continuare la conversazione. Il motivo della scelta è proprio la natura degli oggetti trasmessi: un sito web restituisce spesso pagine piene di link, per cui è lecito assumere che dopo aver letto la mia pagina l'utente potrebbe “navigare” su un altro sito, ovvero richiedere il trasferimento di un altro ipertesto da un altro server.
L'assenza di informazioni sullo stato della comunicazione è uno dei principali grattacapi di chi sviluppa servizi web. La maggior parte delle applicazioni web richiedono infatti di identificare l'utente. Pensiamo ad un banalissimo servizio di web mail, dove usiamo il browser per consultare la nostra casella di posta elettronica. Quando ci logghiamo inseriamo uno username e la password, ma questo avviene una volta sola, e non ogni volta che leggiamo o scriviamo una mail. Com'è possibile tutto ciò se il protocollo http è stateless?
Per capirlo dobbiamo sbirciare dietro le quinte: ogni volta che clicchiamo sul browser, mandiamo un messaggio di richiesta al server, il quale risponde con un messaggio di risposta, che contiene la pagina che verrà visualizzata dal browser (o parte di essa). Al prossimo click invieremo una nuova richiesta, che il server non ha modo di associare alla richiesta precedente, proprio perché si tratta di una nuova comunicazione. Eppure il server risponde inviandomi una pagina appartenente allo stesso contesto della conversazione precedente: se sto consultando la mia casella di posta aprirò un'altra mia mail, e non quella del signor Mario Rossi. Tutto questo accade senza che io debba re-inserire username e password ad ogni click, ovvero senza che io debba identificarmi (o autenticarmi) ogni volta. In termini telefonici: il server non chiede “pronto chi è?” ad ogni telefonata, ma solo la prima volta. La domanda corretta da porsi è quindi: com'è possibile che un web server riconosca lo stesso utente sopra un protocollo stateless?
La risposta sono i cookies HTTP, detti anche web cookies o tracking cookies. Un cookies è un piccolo messaggio extra che il server restituisce al client assieme alla prima risposta: all'interno del cookie il server inserisce un codice speciale, e sempre unico. L'accordo è il seguente:
- il client si impegna a rimandare al server, assieme ad ogni richiesta, il cookie ricevuto con la prima risposta, senza modificarlo
- il server si impegna a tenere traccia dei cookies prodotti, usandoli come codice per riconoscere la sessione dell'utente al fine di identificarlo
Una configurazione troppo permissiva del browser, ovvero la condizione di accettare sempre qualsiasi cookie, può mettere a rischio la nostra privacy. Accettando incondizionatamente lo scambio di cookies rischiamo di identificarci troppo, ovvero di trasmettere al server più dati di quelli necessari. Di contro, una politica troppo severa coi cookies rischia di non farci riconoscere quando serve, e potrebbe quindi rendere impossibile l'utilizzo di qualche servizio online.
L'esempio ci aiuta a giustificare la struttura di un messaggio HTTP:
- Request/Status: tipo di domanda (request-line) o di risposta (status-line)
- Header: informazioni aggiuntive, come ad esempio i cookies
- Body: il messaggio vero e proprio, che nel caso della risposta è la pagina ricevuta
Con questo abbiamo concluso una panoramica sul protocollo HTTP. A seconda delle necessità andremo ad approfondire la parte che ci interessa, come vedremo nelle prossime puntate.
