Appunti di Fondamenti Web

VALIDAZIONE DELLA CACHE

La validazione viene effettuata normalmente mediante richieste condizionali che può avvenire

mediante:

• Ultima modifica: il client effettua una richiesta con l’header If-ModifiedSince, specificando la

data della risorsa cacheata, indicata nel campo Last-Modified della risposta precedentemente

ricevuta. Se la risorsa è stata modificata successivamente alla data indicata, il server risponderà

con un 200 OK insieme alla nuova risorsa; altrimenti il server risponderà con un 304 Not

Modified.

• Etag: viene utilizzata una stringa generata dal server detta ETag che rappresenta una specifica

versione della risorsa (fingerprint). L’ETag viene confrontato con quello presente sul server

mediante If-None-Match: <etag> per controllare se la risorsa è in realtà ancora fresca

FRESHNESS

Le risorse possono cambiare sul server, e in questi casi la cache deve essere aggiornata. Tuttavia, i

server non possono contattare cache e client per avvisarli dell’aggiornamento. Si utilizza, quindi,

un tempo di scadenza, prima del quale la risorsa è considerata fresh (fresca), dopo è considerata

stale (scaduta). Una risorsa scaduta non è necessariamente eliminata o ignorata (a meno di cache

eviction per motivi di spazio), ma bisogna rivalidarla.

La freshness lifetime può essere specificata mediante: l'header Expires con una specifica della

data di scadenza, oppure con l'attributo max-age. Ad esempio: Cache-Control: must-revalidate,

max-age=100. Nei casi in cui né max-age né Expires siano specificati, è possibile determinare la

freshness lifetime in base alla data di ultima modifica.

RISORSE REVVED

Vi sono risorse che possono essere conservate il più a lungo possibile in quanto soggette

raramente a cambiamenti (es: file CSS). Allo stesso tempo, si vuole che, quando questi file

cambiano, essi vengano aggiornati subito. La tecnica del revving prevede di inserire nei nomi dei

file un version number e cachare la risorsa per molto tempo. Il cambiamento dei file revved verrà

effettuato quando anche i file che li utilizzano (di aggiornamento più frequente) saranno

aggiornati.

SUPPORTO PER TRASFERIMENTI CHUNKED

La codifica chunked dei messaggi HTTP è utile quando vengono

trasferite grandi quantità di dati o quando la dimensione totale

del messaggio non è nota fino al termine del trasferimento. In

questo modo i dati vengono trasferiti in blocchi. Il contenuto può essere generato

“dinamicamente” durante il trasferimento. È possibile anche aggiungere header al termine, se non

noti prima.

Per effettuare questo tipo di trasferimento bisogna specificare Transfer-Encoding: chunked nella

richiesta. Questo header codifica il corpo del messaggio HTTP e non la risorsa (per quello esiste

Content-Encoding). All’inizio di ogni chunk va inserita la lunghezza del chunk in formato

esadecimale, seguita da ‘\r\n’. La fine di un chunk è segnalata di nuovo da ‘\r\n’.

CONNESSIONI IN HTTP/1.1

CENNI SU TCP

Come già detto, HTTP è un protocollo applicativo che si basa sul protocollo di trasporto TCP.

Questo permette di stabilire un canale di comunicazione affidabile tra due processi applicativi di

rete. L’affidabilità di TCP è garantita su:

• consegna dei messaggi in termini di ritardo, perdita, ordine ed errore dei pacchetti

• controllo di flusso tra terminali

• controllo di congestione di rete

Il servizio offerto da TCP è, in generale, full-duplex. In altre parole, consente di effettuare

comunicazioni bidirezionali. TCP è un protocollo orientato alla connessione, stabilita mediante una

particolare negoziazione e deve essere chiusa al termine dello scambio di messaggi. La

connessione TCP è associata a un particolare socket (indirizzo IP, porta) aperto da un processo.

L’apertura e la chiusura di una connessione avvengono tramite il metodo three-way handshake

dove il client e il server si mandano segnali di syn e ack per stabilire una connessione. Si definisce

round trip time l’intervallo di tempo che passa dal segnale di syn all’istante in cui quello di ack

mandato arriva.

CONNESSIONI SHORT-LIVED

Prima di HTTP/1.1, le connessioni erano solamente short-lived, permettendo una singola

interazione richiesta-risposta. La creazione di una connessione TCP è sia time-consuming che

resource-consuming. Inoltre, ogni risorsa può richiedere il download di numerose risorse

aggiuntive. Per questo motivo in HTTP/1.1 si è pensato di implementare le connessioni persistenti.

Tutt’ora, in HTTP/1.1 è ancora possibile utilizzare questo modello con l’header Connection: close.

CONNESSIONI MULTIPLE

Le connessioni multiple non sono altre che delle

connessioni short-lived in parallelo (fino a 6).

Tuttavia, questo metodo:

• Crea concorrenza sull’uso della banda da parte delle

varie richieste del client

• Utilizza socket addizionali che consumano risorse su

client e server

• Può essere “limitato” dai server

Questo approccio può dare all’utente l’impressione di un caricamento più veloce.

CONNESSIONI PERSISTENTI Con HTTP/1.1, una connessione persistente può

rimanere aperta per un certo periodo di tempo e

riutilizzata per diverse richieste. A fronte di una

richiesta, se il server decide di mantenere attiva la

comunicazione, userà Connection: Keep-Alive. Il

timeout rappresenta il numero di secondi massimo

durante i quali l’host tiene attiva una connessione

“in pausa”, dopodichè la comunicazione viene

chiusa. Il parametro max rappresenta il massimo

numero di richieste che possono essere inviate su

questa connessione. Purtroppo, una connessione

“in pausa” continua ad occupare risorse.

PIPELINING

La tecnica del pipelining permette al client di fare più richieste contemporaneamente senza dover

necessariamente attendere la risposta del server. Ovviamente i server risponderanno in base

all’ordine di arrivo delle richieste. È importante osservare che solo i metodi idempotenti possono

usare il pipelining. Oggi la maggior parte dei browser non supporta il pipelining a causa di:

• Possibili proxy che non lo supportano

• Difficoltà nell’implementazione delle diverse casistiche

• Code di richieste bloccate da richieste precedenti (head-of-line blocking). Questo perché, se il

server non riesce ad elaborare una richiesta si bloccano anche quelle successive

• Una richiesta fallita può terminare la connessione e forzare a rifare tutte le richieste successive

In assenza di multiplexing e dovendo scongiurare rischi di saturazione delle risorse, nemmeno la

parallelizzazione dell’elaborazione può aiutare a risolvere questi problemi.

VIRTUAL HOSTING

Il virtual hosting permette che richieste a diversi nomi di dominio siano indirizzate su uno stesso

web server. Può essere basato su:

• IP: ogni nome di dominio punta a diversi indirizzi IP attivi sullo stesso web server o a diverse

porte di uno specifico IP di un web server

• Nome: diversi nomi puntano allo stesso IP del web server. Per capire quale applicazione deve

rispondere, deve essere preservata l’informazione sul nome di dominio di destinazione.

Storicamente i proxy eliminavano dalle GET i nomi di dominio lasciando solo i path prima di

inoltrarle all’origin server. Questo è il motivo per cui in HTTP/1.1 è stato introdotto l’header

Host.

MECCANISMI DI AUTENTICAZIONE

HTTP definisce in RFC 7235 un framework di autenticazione per la verifica dell’identità dell’utente,

basato su alcune fasi:

1. Se la risorsa richiesta prevede autorizzazione, il server invia un messaggio di non autorizzazione

(401 Unauthorized) con indicazioni su come

effettuare l’autenticazione. Il realm identifica in

maniera logica quali risorse richiedono determinate autorizzazioni

2. Il browser chiede all’utente username e password associate al realm specificato

3. Se la combinazione username-password è valida

all’interno del realm, il server invia il contenuto

4. Da questo momento il client invierà

automaticamente l’header Authorization in tutte le richieste URL-dipendenti da quella per cui

ha effettuato l’accesso

Con lo schema basic username e password sono in una stringa codificata con base64 e non

crittografata. Per questo motivo, può essere uno schema sicuro solo su una connessione sicura.

Per definire la protezione di file e cartelle, si agisce normalmente mediante direttive sui web

server. Oggi la maggior parte delle applicazioni web implementano i loro schemi di autenticazione

con password inviate tramite POST su connessioni sicure

SUPPORTO ALLE SESSIONI

Come abbiamo detto, HTTP è un protocollo stateless, per cui le richieste sono atomiche e

completamente scollegate l’una dall’altra. La possibilità di estendere HTTP mediante header ha

però permesso la realizzazione di sessioni stateful. Per far ciò è necessario trasferire informazioni

di stato all’interno dei messaggi http. Una tecnica largamente utilizzata è quella dei cookie, stringa

di testo che codifica lo stato che un server invia a un browser, e che il browser invia al server nelle

richieste successive.

IMPOSTAZIONE DI UN COOKIE

L’impostazione di un cookie è una procedura effettuata dal

server. L’header Set-Cookie permette al server di impostare sul

client informazioni di stato oppure un identificatore di sessione

che referenzia uno stato server-side. Al suo interno troviamo

Max-Age e Expires permettono di definire un cookie

“permanente” con una scadenza prefissata. Se non

indicati, il cookie è considerato di sessione ed è

eliminato dal browser “al termine della sessione”. Invece, Domain può essere impostato a un

suffisso dell’host di origine, in modo che il cookie valga per tutti gli host dello stesso tipo.

USO DI UN COOKIE

Ricevuto un cookie, i client devono provvedere alla sua memorizzazione. Questo avviene

all’interno di una memoria del browser. Successivamente, essi utilizzeranno l’header Cookie nelle

richieste successive allo stesso server (o a server collegati) tali che vi sia corrispondenza di

dominio, percorso e porta e invieranno tutti i cookie corrispondenti. In altre parole, questa

operazione serve per identificare il client al server e ricordargli chi è, cosa ha fatto e altri dati utili.

COOKIE FIRST-PARTY E THIRD-PARTY

Quando il cookie è creato dal sito stesso che l'utente sta

visitando, è considerato first-party. Essi svolgono ruoli come:

ricordare le preferenze dell'utente e facilitare esperienza

dell'utent