L’HTTP, acronimo di HyperText Transfer Protocol, è un protocollo di comunicazione utilizzato per scambiare delle informazioni sulla rete.

Ebbene, questa definizione la si può trovare un po’ dovunque, sia su Internet che sui manuali o libri di testo a tema, tuttavia pensiamo che sia molto riduttivo parlarne in questi termini, senza aver dapprima accennato al significato di protocollo.

Infatti, questa parola è assimilabile ad un insieme di regole utilizzate da 2 macchine, al fine di scambiarsi informazioni, specificando inoltre cosa deve essere comunicato, in che modo e quando.

Premesso ciò, questi è stato progettato al fine di consentire la trasmissione e lo scambio di informazioni in un’architettura client-server.

In questo contesto dunque, il client invia una richiesta al server, il quale, prendendola in carico, la elabora e ne produce una risposta, inoltrandola quindi al client.

Pertanto, potremmo immaginare il tutto come una serie di richieste e risposte che avvengono tra 2 macchine, le quali sono connesse tra di loro mediante una rete (locale o Internet).

Nel gergo comune, il client corrisponde dunque al pc, tablet o smartphone dotato di browser, dal quale l’utente o chi per lui effettua una chiamata verso il server; viceversa, il server non è altro che la macchina su cui risiede il sito web o l’applicativo con cui il client sta interagendo.

In tutto ciò, ciascuna richiesta che viene effettuata dal client verso il server è totalmente slegata dalla precedente (da qui la definizione di “protocollo stateless”, ossia privo di stato), al contrario di quanto avviene invece per il protocollo FTP, definito sempre nel 7° livello del modello ISO/OSI.

I protocolli di livello 7 del modello ISO/OSI

Come accennato poc’anzi, il protocollo HTTP differisce dagli altri protocolli (con l’eccezione dell’HTTPS) posti sempre al livello 7 della medesima pila (ossia, tutti i protocolli presenti a livello di applicazione: ultimo step del modello ISO/OSI per le reti di calcolatori).

Fra questi, si annoverano dunque:

• DHCP
• DNS
• SMTP
• SNMP
• POP3
• FTP
• Network Time Protocol (NTP)
• Telnet
• Secure shell (SSH)
• IRC
• Lightweight Directory Access Protocol (LDAP)
• XMPP
• FTAM
• Advanced Program to Program Communications (APPC)
• X.400
• X.500
• AFP
• SIP
• ITMS
• AIM
• TFTP
• NNTP
• Modbus TCP

Perché l’HTTP è un protocollo stateless?

Orbene, la parola “stateless”, abbinata al termine “protocol”, porta fin da subito gli esperti del settore a pensare all’HTTP, in quanto esso è conosciuto proprio come “stateless protocol”, ossia protocollo privo di stato.

Infatti, l’HTTP non mantiene alcun tipo di informazione di stato tra le richieste che si susseguono tra client e server.

Questo significa, infatti, che ogni richiesta viene trattata in maniera indipendente rispetto alla precedente (o alle precedenti).

Pertanto, il server gestirà ciascuna richiesta, successiva alla prima, come se fosse quella iniziale (non tenendo conto di quelle antecedenti).

Tuttavia, sebbene agli occhi di un neofita questo meccanismo potrebbe suonare molto strano, esso non lo è affatto: questa mancanza lo rende effettivamente ideale per il World Wide Web, in quanto le pagine presenti in rete molto spesso contengono dei collegamenti ipertestuali (o link) anche a pagine ospitate su altri server, pertanto, non tenendo conto di tutte le richieste precedenti, il server (o i server che le ospitano) e conseguentemente il client, risultano molto più reattivi ed efficienti.

Detto ciò, questo punto di forza dell’HTTP, rappresenta per certi versi anche il suo tallone d’Achille.

Infatti, per le pagine statiche di un tempo, un protocollo privo di stato era più che sufficiente a garantire una comunicazione tra 2 macchine, in quanto dopo questo botta e risposta, si veniva dirottati di volta in volta su una pagina web costituita perlopiù da contenuto informativo.

Per cui, non era necessario tener conto di tutti i passaggi fatti durante la navigazione, per arrivare fin lì (e per certi versi, questo rappresenta tutt’ora un grande vantaggio).

A conti fatti, per richiamare una specifica pagina HTML (la quale viene quindi interpretata e resa a video dal nostro browser), viene sottomessa una richiesta da parte del client verso il server: ma una volta che la risposta è stata resa, la questione finisce lì.

Infatti, volendo visualizzare un’altra pagina, bisogna effettuare un’altra richiesta, considerata a tutti gli effetti sconnessa dalla precedente (o indipendente da quest’ultima).

Tuttavia, questo meccanismo impatta fortemente con le logiche di un’applicazione web (gestionale, social o e-commerce che sa), in quanto in questi contesti è necessario che ciascuna richiesta sia in qualche modo legata alla precedente, al fine di poter tenere attiva una sessione utente.

In altri termini, con le logiche enunciate fino ad ora, sarebbe praticamente impossibile consentire l’aggiunta di un articolo al carrello di uno shop online e poi continuare la navigazione.

Infatti, passando ad un’altra pagina, si perderebbe tutto lo storico: in altre parole, il server non capirebbe che la richiesta successiva, debba essere ricondotta alla medesima sessione utente.

Indi per cui, il carrello risulterebbe sempre vuoto (in quanto verrebbe distrutto e ricreato di volta in volta)

Ragion per cui, sono stati inventati i cookies.

I cookies

I cookies sono piccoli file di testo che vengono salvati sul proprio computer (o dispositivo mobile) quando si visitano alcuni siti web.

Essi, vengono utilizzati per diversi scopi, come il tracciamento dell’attività di un utente sul sito, oppure per personalizzare il contenuto mostrato a video (ricordando le preferenze espresse precedentemente), come ad esempio la lingua scelta.

In tutto ciò, nel momento in cui si visita nuovamente lo stesso sito, il browser invia i cookies che sono stati salvati sul proprio computer al sito web, in modo tale che quest’ultimo possa riconoscere l’utente stesso e personalizzare il contenuto in base alle sue preferenze.

Inoltre, i cookies possono essere sia “permanenti” (questi rimangono sul proprio dispositivo finché non vengono eliminati manualmente), o temporanei (ci riferiamo a quelli che vengono cancellati automaticamente quando la finestra del browser viene chiusa, quando viene effettuato un logout o quando la sessione utente scade “in maniera naturale”).

Esistono poi, anche i cookies di terze parti, i quali vengono creati da siti web diversi da quello che si sta visitando, al fine di essere utilizzati per raccogliere informazioni sulla propria attività online.

Ad ogni modo, molti siti web utilizzano i cookies per offrire una migliore esperienza di navigazione ai loro utenti.

Tuttavia, è possibile scegliere di disabilitare i cookies o di ricevere un avviso ogni volta che vengono inviati al proprio computer, modificando le impostazioni del proprio browser.

Come viene mantenuta la sessione utente, tramite i cookies, utilizzando il protocollo HTTP?

A questa domanda, rispondiamo subito con un esempio.

Ebbene, nel momento in cui un utente effettua il login ad un’applicazione web, il server invia al browser un cookie che contiene un identificatore univoco per la sessione.

Successivamente, ogni volta che l’utente continuerà ad interagire con la medesima applicazione, la richiesta che ne conseguirà verrà inviata al server, includendo anche il cookie: in modo tale che il server stesso possa conoscere a quale degli utenti al momento loggati si rifaccia.

In questo modo, il server sarà sempre in grado di tener traccia delle azioni compiute dell’utente durante la sessione, al fin di conservare informazioni utili, come ad esempio le sue preferenze o gli articoli presenti nel carrello della spesa online.

Tuttavia, quando l’utente chiuderà la finestra del browser o uscirà dall’applicazione, effettuando il logout (operazione più plausibile), il cookie in questione verrà cancellato dal computer.

Pertanto, se questi provasse fin da subito a tornare sulla pagina home dell’applicativo web (o su quella del carrello), verrebbe immediatamente dirottato sulla pagina di login, in quanto essendo stata invalidata la sessione, mediante operazione di logout, questa non esisterà più: tuttavia, il cookie verrebbe comunque rimandato dal client al server, ma su quest’ultimo non esisterebbe più alcuna corrispondenza con le informazioni ivi presenti sul client.

Motivo per il quale, effettuando nuovamente il login, verrebbe creato un nuovo cookie e contestualmente a ciò, il server creerà una nuova sessione utente (ovviamente, scorrelata dalla precedente).

Al contrario, non effettuando il logout, l’utente potrà continuare a muoversi tranquillamente tra le pagine dell’applicativo (continuando ad effettuare tutte le operazioni consentite).

In tutto ciò, vi è però da aggiungere un altro dettaglio.

Solitamente, dopo un tot di tempo di inattività (quantificabile in 30 minuti, salvo diverse impostazioni), la sessione sul server scadrebbe, mentre il cookie potrebbe essere ancora presente sul client (non avendolo eliminato manualmente).

In questo caso, alla successiva richiesta, il browser invierà questo cookie al server ma non vi sarà più una corrispondenza fra le parti, indi per cui l’utente verrà (anche in questo caso) dirottato sulla pagina di login, al fine di potersi nuovamente loggare (e contestualmente a ciò verrebbe ricreato un nuovo cookie, facente capo alle informazioni della nuova sessione aperta sul server).

Richieste e risposte HTTP

Dopo questa ampia parentesi, passiamo ora alla composizione delle richieste HTTP e alle conseguenti risposte HTTP, unitamente ai metodi chiamati nel contesto delle varie azioni che si intendono eseguire.

Ebbene, i messaggi di richiesta sono costituiti da:

• riga di richiesta (request line)
• sezione header (informazioni aggiuntive)
• riga vuota (CRLF: i 2 caratteri carriage return e line feed)
• body (corpo del messaggio)

mentre le risposte sono costituite da:

• riga di stato (status-line)
• sezione header
• riga vuota (CRLF: i 2 caratteri carriage return e line feed)
• body (contenuto della risposta)

I metodi di richiesta HTTP

Le richieste HTTP possono essere di diversi tipi: GET, POST, PUT e DELETE, a seconda dell’azione che si intende eseguire.

Ad esempio, una richiesta GET viene utilizzata dal cliente al fine di ottenere una risorsa dal server (ad esempio attraverso il click su di un link: operazione in lettura), mentre una richiesta POST viene utilizzata per inviare dei dati dal client al server, al fine di creare una risorsa su quest’ultimo (ad esempio, previo la sottomissione di una form di login: operazione in scrittura).

A queste, si associano poi le richieste PUT, utilizzate per aggiornare risorse già presenti sul server e le richieste di tipo DELETE, utilizzate per eliminare risorse dal server.

I codici di stato HTTP

I codici di stato consistono in una serie di numeri, assegnati ad ogni risposta del server, in corrispondenza di una precedente richiesta.

I codici di stato HTTP vengono dunque utilizzati per indicare se tale richiesta è stata gestita correttamente dal server, se è necessario effettuare ulteriori azioni da parte del client (come l’autenticazione) o se si è verificato un errore durante l’elaborazione della richiesta stessa.

Ad ogni modo, i codici di stato HTTP sono divisi in 5 categorie principali:

• 1xx (Informazionali): questi codici indicano che la richiesta è stata ricevuta dal server e che il processo è in corso
• 2xx (Successo): questi codici indicano che la richiesta è stata gestita correttamente dal server. Ad esempio, il codice di stato 200 (OK) indica che la richiesta è stata elaborata con successo
• 3xx (Reindirizzamento): questi codici indicano che il client deve effettuare ulteriori azioni per completare la richiesta. Ad esempio, il codice di stato 301 (Moved Permanently) indica che la risorsa è stata spostata in maniera permanente e che il client deve utilizzare il nuovo URL fornito nel campo “Location” della risposta.
• 4xx (Errore del client): questi codici indicano che c’è stato un errore nella richiesta del client. Ad esempio, il codice di stato 404 (Not Found) indica che il server non è stato in grado di trovare la risorsa richiesta.
• 5xx (Errore del server): questi codici indicano che c’è stato un errore sul server durante l’elaborazione della richiesta. Ad esempio, il codice di stato 500 (Internal Server Error) indica che c’è stato un errore generico sul server, senza fornire ulteriori dettagli.