Abbiamo già parlato in queste pagine del modello ISO/OSI e dei vari livelli che lo caratterizzano con le tecnologie relative che poi implementano in maniera fisica e logica le singole responsabilità. Se ci posizioniamo nel livello più alto, quello denominato “Applicativo”, a fare da padrone è il protocollo HTTP. Non vogliamo avere la presunzione con questo articolo di analizzare a fondo tutti gli aspetti del protocollo stesso ma solo fare una sintesi, degli appunti essenziali, per i corsi terminali di Sistemi e Reti o TPSIT di quinta superiore degli istituti tecnici.
Indice dei contenuti
Definizione e Storia
Quando facciamo riferimento al mondo delle reti, l’HTTP, ovvero HyperText Transfer Protocol è il principale protocollo usato per la trasmissione di informazioni sul web, che poggia le basi del suo funzionamento sull’architettura client/server . Le specifiche del protocollo sono dettate dal consorzio W3C, che ne ha rilasciato uno dei rari aggiornamenti nel 2022 con la versione HTTP/3.
Il protocollo nasce negli anni 80, assieme agli albori della rete Internet, assieme a tecnologie come il linguaggio HTML per creare le relative pagine, il concetto di URI/URL, i primi server web in ascolto sulla porta 80 e l’uso del protocollo TCP. Se rileggiamo con attenzione l’elenco, un po’ ci viene da ridere: tutte tecnologie semplicissime a cominciare dall’HTML che per i nostri percorsi di studio si esaurisce in una manciata di lezioni o giù di li. Niente di più teneramente comico: la prima internet non è certamente quella caotica e multimediale che conosciamo noi oggi e che i creatori di quaranta anni fa certamente non potevano immaginare. Hardware dalle prestazioni risibili, tecnologie semplici, tutto commisurato al tempo quindi! Occorreva quindi un protocollo semplice ma efficace, lo HTTP.
Messaggio di richiesta
Quando al server web giunge un client, gli pone una serie di informazioni e comandi
- riga di richiesta (request line);
- sezione header (informazioni aggiuntive);
- riga vuota;
- body (corpo del messaggio)
Vediamo con qualche dettaglio in più.
Riga di richiesta
La riga di richiesta è composta da un metodo, un URI ed una versione del protocollo. Il metodo altro non è un comando elementare, una primitiva con uno scopo preciso:
- GET
- POST
- HEAD
- PUT
- DELETE
- PATCH
- TRACE
- OPTIONS
- CONNECT
Quelli da tenere obbligatoriamente in considerazione sono il GET e POST, un po’ meno lo HEAD per applicazioni più spinte.
I metodi HTTP più comuni e che conviene ricordarci sono GET, POST e HEAD. Il metodo GET è usato per ottenere il contenuto della risorsa specificata nel URI (cad es. una pagina HTML). HEAD è del tutto simile a GET ma restituisce solo i campi dell’header che vedremo più avanti per la gestione non tanto della pagina ma delle informazioni ad essa aggiunte. Il metodo POST è usato di norma per inviare informazioni al server che per noi avverrà quasi sempre attraverso le form. Se nel GET il contenuto della richiesta è visibile nella barra dell’URL, nel POST le nformazioni vengo nascoste nel contenuto del body, tecnica molto utile per preservare dati sensibili da occhi indiscreti.
Gli header della richiesta
Con ogni richiesta GET/HEADER, alcune informazioni viaggiano tra server e client che oggi sembrano irrinunciabili. Gli header di richiesta più comuni sono:
- Host: nome del server a cui si riferisce l’URL. È obbligatorio dalla versione HTTP/1.1 perché permette l’uso dei virtual host basati sui nomi.
- User-Agent: identificazione del tipo di client: tipo browser, produttore, versione e quindi indirettamente il dispositivo con cui si sta navigando, che sia un pc, uno smartphone o tablet. Questo può tornare vincente per il programmatore che può allestire più versioni del sito web in funzione dello User-Agent che fa visita.
- Cookie: utilizzati dalle applicazioni web per archiviare e recuperare informazioni a lungo termine sul lato client. Spesso usati per memorizzare un token di autenticazione o per tracciare le attività dell’utente nel caso di cookie di terze parti soprattutto..
Messaggio di risposta
Il messaggio di rispostaè anche esso formato da più parti, quattro per la precisione
- riga di stato (status-line);
- sezione header;
- riga vuota (CRLF: i 2 caratteri carriage return e line feed);
- body (il contenuto vero e proprio della risposta).
Riga di stato
La riga di stato riporta un codice a tre cifre catalogato nel seguente modo:
- 1xx: Informational (messaggi informativi)
- 2xx: Successful (la richiesta è stata soddisfatta, nel body ci sarà il contenuto richiesto)
- 3xx: Redirection (non c’è risposta immediata, ma la richiesta è sensata e viene reindirizzato altrove per ottenere la risposta)
- 4xx: Client error (la richiesta non può essere soddisfatta perché sbagliata)
- 5xx: Server error (la richiesta non può essere soddisfatta per un problema interno del serve
Sezione Body
Il body conterrà finalmente il contenuto richiesto. Nella maggioranza dei casi, per noi utenti normali, sarà una pagina di testo HTML ma non certo l’unica tipologia. Questa è specificata nel MIME/Type dell’header di risposta. Il contenuto, lo vedremo anche su queste pagine, potrebbe essere ancora un testo ma in formato XML o JSON, oppure un altro formato immagine tipo JPG, PNG, WEBP ecc, video ecc
Persistenza
Come già ribadito, il protocollo HTTP nasce semplice per le circostanze hw/sw del tempo. Ha un terribile difetto: non ha memoria, ovvero tra una pagina e l’altra, magari legate da un link dello stesso sito, non c’è la possibilità di mantenere delle informazioni. O almeno così nasce il protocollo: ogni richiesta/URI ha una sua vita individuale.
Esistono però, e le vedremo, delle tecniche per lo scambio di dati e variabili tra pagine: i cookies e le sessioni.
Sicurezza
Il protocollo nasce senza misure di sicurezza. Già col GET abbiamo detto che i dati viaggiano in chiaro sulla URL. Ovviamente il problema della sicurezza si è posto in seguito agli albori di internet e HTTP. Ecco perché è stato aggiunto un protocollo SSL prima e TLS dopo che danno forza dallo strato TCP al servizio HTTP per procedere con un canale crittografato tra le parti connesse.
Ultima modifica 10 Novembre 2023
