Il protocollo HTTP

Il protocollo HTTP, ovvero Hyper Text Transfer Protocol, in italian protocollo di trasferimento di un ipertesto, è probabilmente il protocollo di livello Application più utilizzato nelle comunicazioni tramite la rete Internet, ovvero nell’ambito di una tipica architettura Client-Server. Le specifiche di questo protocollo sono gestite dal World Wide Web Consortium (W3C). Un Server HTTP generalmente resta in ascolto delle richieste dei Client sulla porta 80 usando il protocollo TCP a livello Transport.

Funzionamento

Il protocollo HTTP lavora gestendo lo scambio di messaggi dell’architettura Client-Server secondo il seguente schema: il Client invia una richiesta al Server, il quale restituisce la risposta a tale richiesta. Il tipo esempio di architettura Client-Server è costituito da un dispositivo che, tramite un Browser, effettua la richiesta di una pagina web ad un Server. I messaggi HTTP sono quindi di due tipi: messaggi di richiesta e messaggi di risposta.

A differenza di altri protocolli di livello Application, che prevedono una chiusura esplicita della connessione tra due host (come ad esempio il protocollo FTP), nell’HTTP le connessioni vengono automaticamente chiuse una volta che la richiesta dell’host Client viene soddisfatta. Questo comportamento è ideale nell’ambito del World Wide Web, dove i server contengono pagine che a loro volta ospitano link ad altre pagine e quindi è molto facile, anzi frequentissimo, dover passare da un Server all’altro, con la necessità quindi di aprire nuove connessioni e di conseguenza dover chiudere quelle soddisfatte e non più necessarie, in modo da diminuire il numero di connessioni attive limitandolo a quelle necessarie. Uno dei principali inconvenienti di questo protocollo è tuttavia la sua condizione di protocollo stateless, ovvero senza stato, cioè incapace di mantenere memoria delle sessioni di navigazione dell’utente. Questa particolarità ha costretto gli sviluppatori di contenuti per il Web ad adottare metodi alternativi per tenere traccia dello stato di navigazione dell’utente, come ad esempio i cookie.

Messaggi di richiesta

Nel protocollo HTTP un messaggio di richiesta è composto di quattro parti:

• Riga di richiesta (request line);
• Header (informazioni aggiuntive);
• Riga vuota (CRLF: i 2 caratteri carriage return e line feed);
• Body (corpo del messaggio).

Riga di richiesta (request line)

La riga di richiesta è composta da metodo, URI (Uniform Resource Identifier) e versione del protocollo. Il metodo di richiesta a sua volta può essere di diversi tipi. La specifica 1.1 del protocollo prevede i seguenti:

• GET
• POST
• HEAD
• PUT
• DELETE
• PATCH
• TRACE
• OPTIONS
• CONNECT

Chiariamo che con il termine di URI si indica l’oggetto della richiesta, ad esempio l’indirizzo della pagina web che si intende ottenere dal server.

I metodi HTTP più utilizzato sono GET, HEAD e POST.

Il metodo GET è usato per ottenere il contenuto della risorsa indicata come URI. Il metodo HEAD è analogo a GET, ma restituisce solo i campi dell’header (una richiesta effettuata con metodo HEAD non prevede l’uso del body) ad esempio per verificare informazioni di sistema non direttamente correlate ai dati, come la data di ultima modifica di un file.

Il metodo POST invece è usato prevalentemente per inviare informazioni al Server: esempio tipico di questo metodo sono i form di contatto che possono essere compilati in alcune pagine web e causano l’invio di una mail. In questo caso l’URI indica che cosa si sta inviando e il body ne indica il contenuto.

Header (informazioni aggiuntive);

Il campo header come sappiamo non è strettamente correlato al contenuto intrinseco del messaggio, ma è utilizzato per trasportare informazioni aggiuntive. Le principali informazioni comunicate tramite l’header sono il nome Host, ovvero il server a cui l’URL si riferisce, lo User Agent, ovvero il tipo di client usato (tipicamente il tipo browser e la relativa versione) e i Cookie, ovvero dei file di testo che memorizzano sulla macchina cliente delle informazioni sulla sessione di navigazione per sopperire parzialmente alla condizione di protocollo Stateless propria di HTTP.

Linea vuota

La line vuota contiene solo 2 caratteri, che sono il carriage return, ovvero il ritorno a capo, e il line feed, ovvero l’avanzamento di riga.

Body

Il message Body, come facilmente intuibile, è costituito dai dati che si vogliono effettivamente trasmettere al destinatario.

Messaggio di risposta

Il messaggio di risposta è di tipo testuale ed è composto da quattro parti:

• Riga di stato (status-line);
• Header;
• Riga vuota (CRLF: i 2 caratteri carriage return e line feed);
• Body (contenuto della risposta).

Riga di stato

La riga di stato riporta i cosiddetti codici di stato http, ovvero informazioni aggiuntive circa l’esito della connessione ed eventuali errori. Tali codici sono classificati in 5 categorie, a seconda del tipo di stato da riportare, e formati da codici di 3 cifre. Le categorie sono le seguenti:

• 1xx: Informational (messaggi informativi)
• 2xx: Successful (la richiesta è stata soddisfatta)
• 3xx: Redirection (non c’è risposta immediata, ma la richiesta è valida viene detto come 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 server)

I codici di risposta più comuni sono invece i seguenti

• 200 OK. Il server ha fornito correttamente il contenuto nella sezione body.
• 301 Moved Permanently. La risorsa che richiesta non è più disponibile in quanto è stata spostata in modo permanente.
• 302 Found. La risorsa è raggiungibile con un altro URI indicato nel header Location. Di norma i browser eseguono la richiesta all’URI indicato in modo automatico senza interazione dell’utente.
• 400 Bad Request. La risorsa richiesta non è comprensibile al server.
• 404 Not Found. Il Client error più famoso e probabilmente più comune: indica che la risorsa richiesta non è stata trovata e non se ne conosce l’ubicazione. Di solito avviene quando l’URI è stato indicato in modo incorretto, oppure quando la risorsa che era presente a quell’URI è stata rimossa dal server.
• 500 Internal Server Error. Il server non è in grado di rispondere alla richiesta per un suo problema interno. Si tratta di uno degli errori più insidiosi che si possono riscontrare, dato che non fornisce indicazioni di alcun genere circa la natura del problema riscontrato.
• 502 Bad Gateway. Il server web che agisce come reverse proxy non ha ottenuto una risposta valida dal server di upstream.
• 505 HTTP Version Not Supported. La versione di http non è supportata.

Header

I più comuni header dei messaggi di risposta sono i seguenti:

• Server. Indica il tipo e la versione del server. Può essere visto come l’equivalente dell’header di richiesta User-Agent
• Content-Type. Indica il tipo di contenuto che viene restituito, che può essere di vario genere. I tipi disponibili sono detti Media Type e sono codificati dallo IANA (Internet Assigned Number Authority). I più comuni Media Type sono i seguenti:
  • text/html Documento HTML
  • text/plain Documento di testo non formattato
  • text/xml Documento XML
  • image/jpeg Immagine di formato JPEG

Tipologie di connessioni HTTP

Esistono due tipologie di connessione che il client può chiedere al server:

Connessione non persistente

Per ogni richiesta e relativa risposta, viene stabilita una connessione TCP dedicata.

Connessione Persistente

Per ogni richiesta, e relativa risposta, la comunicazione avviene utilizzando la stessa connessione TCP. Questo è il comportamento di default della versione 1.1 di HTTP.

Le due tipologie di connessione presentano ovviamente caratteristiche abbastanza diverse: da una parte le connessioni non persistenti introducono una latenza aggiuntiva alla comunicazione rispetto a quelle persistente. Dall’altra parte però le connessioni persistenti, a fronte di una latenza minore, non possono usufruire dei vantaggi del parallelismo di comunicazione, dal momento che un cliente che deve gestire parecchie richieste contemporaneamente non potrà evaderle se non in maniera sequenziale, una dopo l’altro.

Per questo motivo, infatti, i client (tipicamente i browser) solitamente sfruttano entrambe le tipologie di connessione per cercare di ottimizzare prestazioni ed efficienza e quindi di solito aprono con ogni server diverse connessioni TCP in parallelo, che poi utilizzano per comunicare con tipologia persistente.

Versioni sicure del protocollo HTTP

Nonostante le sue caratteristiche di affidabilità e performance, il protocollo HTTP presenta il difetto di effettuare le comunicazioni completamente in chiaro e in maniera anonima, con i relativi problemi di sicurezza. Per ovviare a questo inconveniente sono state sviluppate le versioni sicure, che implementano ulteriori funzionalità, finalizzate alla cifratura del traffico, al controllo dell’integrità dei messaggi scambiati e all’autenticazione tra client e server.

La versione oggi più utilizzata è HTTPS, HyperText Transfer Protocol over Secure Socket Layer. Questo protocollo estende HTTP in ottica di incrementare notevolmente la sicurezza. La porta logica utilizzata generalmente (ma non necessariamente) è la 443, contro la porta 80 utilizzata da HTTP. Essenzialmente HTTPS stabilisce una comunicazione tramite il protocollo HTTP all’interno di una connessione criptata, tramite crittografia asimmetrica, create dal Transport Layer Security (TLS) o dal suo predecessore, Secure Sockets Layer (SSL) fornendo come requisiti chiave un sistema di autenticazione del sito web visitato, una protezione della privacy e garantendo l’integrità sui dati scambiati.