031.3 Lezione 1

Il primo stadio di uno scambio di dati HTTP tra il client e il server è iniziato dal client, quando scrive un messaggio di richiesta al server. Prendiamo, per esempio, un compito comune del browser: caricare una pagina HTML da un server che ospita un sito web, come https://learning.lpi.org/it/. L’indirizzo, o URL, fornisce diverse informazioni rilevanti. Tre informazioni appaiono in questo particolare esempio:

Dopo che il server HTTP ha ricevuto l’intestazione del messaggio di richiesta, il server restituisce un messaggio di risposta al client. Una richiesta di file HTML ha tipicamente un’intestazione di risposta come questa:

La prima riga fornisce la versione del protocollo HTTP usata nel messaggio di risposta, che deve corrispondere alla versione usata nell’intestazione della richiesta. Poi, sempre nella prima riga, appare il codice di stato della risposta, che indica come il server ha interpretato e generato la risposta per la richiesta.

Il codice di stato è un numero di tre cifre, dove la cifra più a sinistra definisce la classe di risposta. Ci sono cinque classi di codici di stato, numerate da 1 a 5, ognuna delle quali indica un tipo di azione intrapresa dal server:

La seconda e la terza cifra sono usate per indicare ulteriori dettagli. Il codice 200, per esempio, indica che è stato possibile rispondere alla richiesta senza problemi. Come mostrato nell’esempio, può essere fornita anche una breve descrizione testuale dopo il codice di risposta (OK). Alcuni codici specifici sono di particolare interesse per assicurare che il client HTTP possa accedere alla risorsa in situazioni avverse o per aiutare a identificare il motivo del fallimento nel caso di una richiesta non riuscita:

Pur indicando che non è stato possibile soddisfare la richiesta, i codici di stato 4xx e 5xx indicano che il server HTTP è in funzione ed è in grado di ricevere richieste. I codici 4xx richiedono un’azione da parte del client, perché l’URL o le credenziali sono sbagliate. Al contrario, i codici 5xx indicano qualcosa di sbagliato sul lato server. Quindi, nel contesto delle applicazioni web, queste due classi di codici di stato indicano che la fonte dell’errore si trova nell’applicazione stessa, sia client sia server, non nell’infrastruttura sottostante.

I server HTTP utilizzano due meccanismi di base per soddisfare il contenuto richiesto dal client. Il primo meccanismo fornisce contenuto statico: cioè, il percorso indicato nel messaggio di richiesta corrisponde a un file sul file system locale del server. Il secondo meccanismo fornisce contenuto dinamico: cioè, il server HTTP inoltra la richiesta a un altro programma - probabilmente uno script - per costruire la risposta da diverse fonti, come database e altri file.

Anche se ci sono diversi server HTTP, tutti usano lo stesso protocollo di comunicazione HTTP e adottano più o meno le stesse convenzioni. Un’applicazione che non ha una necessità specifica può essere implementata con qualsiasi server tradizionale, come Apache o NGINX. Entrambi sono in grado di generare contenuti dinamici e fornire contenuti statici, ma ci sono sottili differenze nella configurazione di ciascuno di essi.

La posizione dei file statici da servire, per esempio, è definita in modi diversi in Apache e NGINX. La convenzione è di tenere questi file in una directory specifica per questo scopo, con un nome associato all’host, per esempio /var/www/learning.lpi.org/. In Apache, questo percorso è definito dalla direttiva di configurazione DocumentRoot /var/www/learning.lpi.org, in una sezione che definisce un host virtuale. In NGINX, la direttiva usata è root /var/www/learning.lpi.org in una sezione server del file di configurazione.

Qualsiasi server tu scelga, i file in /var/www/learning.lpi.org/ saranno serviti via HTTP quasi allo stesso modo. Alcuni campi nell’intestazione della risposta e i loro contenuti possono variare tra i due server, ma campi come Content-Type devono essere presenti nell’intestazione della risposta e devono essere coerenti su qualsiasi server.

HTTP è stato progettato per funzionare su qualsiasi tipo di connessione Internet, veloce o lenta. Inoltre, la maggior parte degli scambi HTTP deve attraversare molti nodi di rete a causa dell’architettura distribuita di Internet. Di conseguenza è importante adottare qualche strategia di caching dei contenuti per evitare il trasferimento ridondante di contenuti precedentemente scaricati. I trasferimenti HTTP possono funzionare con due tipi base di cache: condivisa e privata.

Una cache condivisa è usata da più di un singolo client. Per esempio, un grande fornitore di contenuti potrebbe usare cache su server geograficamente distribuiti, in modo che i client ricevano i dati dal server più vicino. Una volta che un client ha fatto una richiesta e la sua risposta è stata memorizzata in una cache condivisa, altri client che fanno la stessa richiesta nella stessa area riceveranno la risposta presente nella cache.

Una cache privata è creata dal client stesso per il suo uso esclusivo. È il tipo di cache che il browser web fa per le immagini, i file CSS, il JavaScript o il documento HTML stesso, in modo che non debbano essere scaricati di nuovo se richiesti in un prossimo futuro.

Sia la strategia della cache condivisa sia quella della cache privata usano le intestazioni HTTP per controllare come il contenuto scaricato dovrebbe essere messo in cache. Per la cache privata, il client consulta l’intestazione della risposta e verifica se il contenuto nella cache locale corrisponde ancora al contenuto remoto corrente. Se è così, il client rinuncia al trasferimento del payload della risposta e usa la versione locale.

La validità della risorsa in cache può essere valutata in diversi modi. Il server può fornire una data di scadenza nell’intestazione di risposta per la prima richiesta, in modo che il client scarti la risorsa in cache alla fine del termine e la richieda nuovamente per ottenere la versione aggiornata. Tuttavia, il server non è sempre in grado di determinare la data di scadenza di una risorsa, quindi è comune usare il campo intestazione di risposta ETag per identificare la versione della risorsa, per esempio Etag: "606adcd4-46fa".

Per verificare che una risorsa in cache debba essere aggiornata, il client richiede al server solo la sua intestazione di risposta. Se il campo ETag corrisponde a quello della versione memorizzata localmente, il client riutilizza il contenuto della cache. Altrimenti, il contenuto aggiornato della risorsa viene scaricato dal server.

In un sito web convenzionale o in un’applicazione web, le funzioni che gestiscono il controllo della sessione sono basate sulle intestazioni HTTP. Il server non può assumere, per esempio, che tutte le richieste provenienti dallo stesso indirizzo IP siano dello stesso client. Il metodo più tradizionale che permette al server di associare diverse richieste a un unico client è l’uso di cookies, un tag di identificazione che viene dato al client dal server e che viene fornito nell’intestazione HTTP.

I cookie permettono al server di conservare informazioni su un client specifico, anche se la persona che lo esegue non si identifica esplicitamente. Con i cookie è possibile implementare sessioni in cui i login, i carrelli della spesa, le preferenze, ecc. vengono conservati tra diverse richieste fatte allo stesso server che li ha forniti. I cookie vengono utilizzati anche per tracciare la navigazione degli utenti, quindi è importante chiedere il consenso prima di inviarli.

Il server imposta il cookie nell’intestazione della risposta usando il campo Set-Cookie. Il valore del campo è una coppia nome=valore scelta per rappresentare qualche attributo associato a uno specifico client. Il server può, per esempio, creare un numero di identificazione per un client che richiede una risorsa per la prima volta e passarlo al client nell’intestazione di risposta:

Se il client permette l’uso di cookie, le nuove richieste a questo stesso server hanno il campo cookie nell’intestazione:

Con questo numero di identificazione, il server può recuperare definizioni specifiche per il client e generare una risposta personalizzata. È anche possibile utilizzare più di un campo Set-Cookie per fornire diversi cookie allo stesso client. In questo modo, più di una definizione può essere conservata sul lato client.

I cookie sollevano sia problemi di privacy sia potenziali falle di sicurezza, perché c’è la possibilità che possano essere trasferiti a un altro client, che sarà identificato dal server come il client originale. I cookie utilizzati per preservare le sessioni possono dare accesso a informazioni sensibili del client originale. Pertanto, è molto importante che i client adottino meccanismi di protezione locale per evitare che i loro cookie siano estratti e riutilizzati senza autorizzazione.