Fondamenti del Web

Ingegneria del Software e Fondamenti Web

Corso di Laurea in Ingegneria

Informatica e dell’Automazione
Anno Accademico 2023/2024

Prof. Antonio Ferrara

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
 2 I protocolli
URI e HTTP
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Uniform Resource
Locator
All'interno del Web, ogni risorsa è associata ad una locazione univoca che permette di raggiungerla

Tale locazione viene generalmente specificata:

• digitando la locazione nella barra degli indirizzi di un browser
• come link associato ad un testo o a un pulsante
• da uno script che si occupa del reperimento/invio di informazione

Lo standard introdotto con il World Wide Web da Berners-Lee nel 1994 è chiamato Uniform Resource Locator (URL)

http://www.mywebsite.com/sj/test.html

Con il tempo, lo standard URL è stato generalizzato in URI, da cui sono poi emerse altre specializzazioni

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Uniform Resource
Identifier
URI Uniform Resource Identifier (RFC 3986 del 2005) è uno standard per l'identificazione di una risorsa (oggetti,
persone, posti, concetti, risorse web, …) in maniera univoca mediante locazione o nome o entrambi
Gli URI hanno due possibili specializzazioni, elencate di seguito

URL Uniform Resource Locator è uno standard introdotto nel 1994 (RFC 1738) da Berners-Lee, pensato per il
Web ma utilizzato per numerosi altri servizi
Un URL specifica la localizzazione di una risorsa su una rete e il meccanismo necessario per ottenerla
Esempi sono i seguenti:
http://www.ietf.org/rfc/rfc2396.txt
ftp://ftp.is.co.za/rfc/rfc1808.txt
mailto:[email protected]

URN Uniform Resource Name è un URI che fornisce identificatori e nomi globali e persistenti a determinate risorse,
all’interno di specifici namespace, ma non può essere usato per la loro localizzazione
È composto di un Namespace Identifier (NID) e di un Namespace Specific String (NSS)
Un esempio di URN è l’identificativo di un libro nel namespace di ISBN, ad es. urn:isbn:0451450523

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Uniform Resource
Identifier
URI è stato pensato per essere flessibile, estensibile e utilizzabile anche con altri protocolli oltre HTTP

http://www.mywebsite.com:80/sj/test?name=bob&x=true#label

mailto:[email protected]

spotify:track:6eTGxxQxiTFE6LfZHC33Wm

urn:isbn:0-395-36341-1

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
 Uniform Resource
Identifier
Il path è sempre definito e rappresenta univocamente la risorsa
Lo schema identifica il meccanismo L'organismo IANA si o
ccupa
di registrare gli schem Nel caso del Web, viene interpretato dal web server:
con cui la risorsa deve essere reperita, i per
gli URI • come un percorso a un file statico
oppure indica che si tratta di un URN:
https://www.iana.org
/
• come il percorso di un programma che genera una risposta HTML
http, https, file, mailto, assignments/uri-sche
mes/ • mediante un preciso routing a particolare funzioni (API), ad es. /
websocket, spotify, urn, ...
users/create o /users/delete/0x23433

Il componente di authority Alcuni esempi...

(facoltativo) può esprimere userinfo host port
informazioni sull'utente e ┌──┴───┐ ┌──────┴──────┐ ┌┴┐
https://[email protected]:123/forum/questions/?tag=networking&order=newest#top
sull'host che si vuole raggiungere └─┬─┘ └─────────────┬────────────┘└───────┬───────┘ └────────────┬────────────┘ └┬┘
scheme authority path query fragment
in forma di registered name o
indirizzo IP mailto:[email protected] urn:oasis:names:specification:docbook:dtd:xml:4.1.2
└─┬──┘ └────┬─────────────┘ └┬┘ └──────────────────────┬──────────────────────┘
scheme path scheme path

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Uniform Resource
Identifier
URI relativi

Quando un URI non inizia con uno schema seguito dai due punti, si tratta di un URI relativo, ovvero di un path che sarà
risolto in un URI mediante associazione ad un base URI inferito dal contesto o dall'URI attuale

Supponendo di essere all'interno di una rappresentazione con URI http://a/b/c/d?q, di seguito sono presentati alcuni
possibili URI relativi e le loro risoluzioni

"g" -> "http://a/b/c/g" "" -> "http://a/b/c/d?q"

"./g" -> "http://a/b/c/g" "." -> "http://a/b/c/"
"/g" -> "http://a/g" "./" -> "http://a/b/c/"
"//g" -> "http://g" ".." -> "http://a/b/"
"?y" -> "http://a/b/c/d?y" "../" -> "http://a/b/"
"g?y" -> "http://a/b/c/g?y" "../g" -> "http://a/b/g"
"#s" -> "http://a/b/c/d?q#s" "../.." -> "http://a/"
"g#s" -> "http://a/b/c/g#s" "../../" -> "http://a/"
"g?y#s" -> "http://a/b/c/g?y#s" "../../g" -> "http://a/g"

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
HyperText
Transfer Protocol
HTTP è un protocollo di livello applicativo nella suite TCP/IP, che usa TCP come livello di trasporto (o una connessione TLS-
encrypted)
È il protocollo fondante del Web e regola gli scambi di dati nel web

HTTP permette ai client di ottenere risorse presenti sui

server web mediante specifiche richieste, nonché di
inviare contenuti a server web

La comunicazione avviene scambiando singoli messaggi

fra client e server mediante il paradigma richiesta-
risposta, ed è di regola iniziata dal recipient (solitamente
il browser, oppure un robot come un crawler)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Componenti di
sistemi HTTP-based
Il ruolo del client è generalmente ricoperto dall’utente che richiede le risorse per mezzo del suo user-agent
Lo user-agent è solitamente il browser, ma può essere qualunque altro programma o qualunque robot

Di regola, la richiesta HTTP è iniziata dal client, ma nel tempo si sono proposti meccanismi per simulare il contrario

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Componenti di
sistemi HTTP-based
Il server accetta connessioni HTTP e genera risposte
Appare virtualmente come una singola macchina capace di servire risorse
In realtà può trattarsi di una collezione di macchine che condividono il carico delle richieste (load balancing) o un software che
interroga computer diversi che generano parti diverse del documento (cache, database server, etc.)
Nella situazione opposta, su una stessa macchina possono trovarsi più web server che condividono l’indirizzo IP

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Componenti di
sistemi HTTP-based
Fra un client e un server possono esserci numerose entità chiamate proxy, che eseguono diverse operazioni:
• firewall
• filtraggio delle richieste
• caching
• load balancing
• autenticazione
• logging

Client Proxy Reverse proxy Server

I proxy agiscono a livello applicativo (non sono quindi da confondere con i diversi attori coinvolti a livello di
trasporto o di rete)
Fungono sia da server che da client, agendo in maniera trasparente (se non modificano la richiesta – gateway)
o non trasparente (se la modificano prima di passarla al server)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Flusso di
HTTP

1 Identificazione della risorsa mediante il suo URI

2 Lo user agent apre una connessione TCP col server o ne utilizza una già esistente

3 La richiesta viene trasformata in un messaggio di richiesta HTTP

3 La richiesta passa, eventualmente, attraverso uno o più proxy

4 Il server riceve la richiesta e prova a generare una risposta

5 Un messaggio HTTP di risposta viene inviato dal server allo user agent (passando attraverso eventuali proxy)

6 Lo user agent mostra (o utilizza) la risorsa ricevuta

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Flusso di
HTTP
Nella realtà, il processo di richiesta e risposta fra client e server può non terminare dopo aver ricevuto la risorsa principale
Le pagine HTML possono contenere riferimenti a una serie di altre risorse esterne
(es. immagini, fogli di stile, script, oggetti multimediali, applet)
Quando uno user agent può gestire il rendering di immagini o di stili, o l’esecuzione di script, deve determinare quali sono le
risorse aggiuntive necessarie e generare richieste HTTP aggiuntive per ottenerle

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Caratteristiche
di HTTP
• HTTP è un protocollo estremamente semplice e human-readable, e questo è sempre stato il suo punto di forza

• HTTP è estensibile grazie agli header che possono essere inclusi in richieste e risposte

• HTTP è un protocollo stateless: ogni richiesta è considerata come una singola interazione, e non vi è alcun “collegamento” fra
due richieste successive (si veda la differenza con SMTP, FTP, …)

• HTTP permette comunque la realizzazione di sessioni stateful, mediante l’utilizzo dei cookie (grazie all’estensibilità degli
header)

• Prima di HTTP/1.1 per ogni richiesta veniva effettuata una connessione TCP (nessuna possibilità di fare un batch di richieste):
ciò in concordanza al fatto che HTTP è stateless

• Con HTTP/1.1 le connessioni possono essere persistenti, ma con una politica “best-effort” (non sono pensate, quindi, per
mantenere lo stato)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Versioni di
HTTP
0.9 1991 Protocollo “a una riga” che serviva al client il file HTML richiesto

1.0 1996 Proposta non vincolante, introduceva nuovi metodi di richiesta ed header per specificare meglio richieste e
risposte
Fra gli altri, fu introdotto l’header Content-Type che ha permesso di trasmettere file diversi da HTML
RFC 1945

1.1 1997 Primo standard ufficiale, oggi ancora in uso

Introduce meccanismi di caching, negoziazione del contenuto, trasferimenti chunked, multi-homing e
connessioni persistenti (non è necessario stabilire una connessione per ogni richiesta)
RFC 2068, 2069, 2616, 2617

2.0 2015 Introduzione di strategie per il multiplexing dei messaggi su una singola connessione, con incapsulamento
dei messaggi all’interno di frame
RFC 7540

3.0 2022 L'ultima versione di HTTP usa QUIC di Google al posto di TCP, basato su UDP, ma affidabile

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Messaggi
HTTP

generic-message = start-line
A proposito di CRLF
*(message-header CRLF)
CRLF Indica, storicamente, un Carriage Return and Line
[ message-body ] Feed, per spostare il “cursore” all’inizio della riga e
poi una linea in basso
start-line = Request-Line | Status-Line
Utilizzato in HTTP per delimitare i diversi campi
message-header = field-name ":" [ field-value ]
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>

Alcuni estratti da RFC 2616

Con HTTP/2 i messaggi (prima human-readable) sono divisi in frame a fini di ottimizzazione e performance

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Richieste
HTTP
Metodi di richiesta in HTTP 1.1

• GET (richiesta di una risorsa, anche condizionale,

METHOD /path-to-resource HTTP/version-number eventualmente corredata da una query string)
Header-Name-1: value • HEAD (richiesta dell’header di una risorsa)
Header-Name-2: value • POST (invio di informazioni ad una risorsa esistente)
...
• PUT, OPTIONS, DELETE, TRACE, CONNECT

[optional request body] Proprietà dei metodi HTTP

Il protocollo HTTP indica alcune proprietà per la

classificazione dei metodi
GET /it/index.html HTTP/1.1 • metodi safe: si tratta di metodi read-only, non cambiano
Host: www.poliba.it lo stato del server
• metodi idempotenti: l’effetto di ripetute richieste
identiche è lo stesso di quello di una sola richiesta (metodi
safe sono anche idempotenti)
• metodi cacheable: le loro risposte possono essere
memorizzate in cache dai client
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Richieste
HTTP
Metodo GET

GET /q?s=YHOO HTTP/1.1

Host: finance.yahoo.com
User-Agent: Mozilla/5.0

• Il metodo GET per la richiesta di risorse è invocato quando si scrive un

URL nel browser o si clicca su un link ipertestuale Sicuro? "
• Prevede obbligatoriamente l’header Host e l’assenza di un corpo
• È possibile inviare una query string dopo il simbolo ? con i parametri di Idempotente? "
una richiesta (usato, ad esempio, per inviare i dati inseriti all’interno di un
form): attenzione alla semantica! Cacheable? "

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Richieste
HTTP
Metodo POST

POST /q HTTP/1.1
Host: finance.yahoo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 6

s=YHOO

Sicuro? #
• Il metodo POST permette di effettuare richieste contenenti un corpo
• Usato per inviare blocchi di dati (es. campi di un form), postare messaggi, Idempotente? #
creare nuove risorse
• Semanticamente serve per rappresentare una nuova entità Cacheable? $
• A causa del fatto che i browser supportano solo GET e POST, questo metodo * Solo se è inserita
informazione su
viene utilizzato per molti tipi di task di invio e gestione dati, alterazione ed
freshness
eliminazione di record

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Richieste
HTTP
Metodo HEAD

HEAD / HTTP/1.1
Host: poliba.it
User-Agent: Mozilla/5.0

• Il metodo HEAD permette di ricevere l’header di una risorsa

Sicuro? "
per verificare la validità e l’accessibilità di un URI o per
motivi di caching (confrontando l’header Last-Modified
Idempotente? "
della risposta) Cacheable? "

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Richieste
HTTP
Metodi PUT e DELETE

PUT /new.html HTTP/1.1 DELETE /file.html HTTP/1.1

Host: example.com
Content-type: text/html
Content-length: 16

<p>New File</p>
Sicuri? #
• PUT e DELETE permettono di inserire e rimuovere risorse su un server Idempotenti? "
• PUT si differenzia da POST per l’idempotenza: diverse PUT identiche non
producono side effect, mentre diverse POST possono causare effetti addizionali Cacheable? "
(es. più righe in un DB o più articoli comprati)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Richieste
HTTP
Panoramica

GET HEAD POST PUT DELETE

Corpo nella richiesta No No Sì Sì Può
Corpo nella risposta Sì No Sì No Può
Sicuro Sì Sì No No No
Idempotente Sì Sì No Sì Sì
Cacheable Sì Sì * No No
Permesso in form HTML Sì No Sì No No

* Solo se è inserita informazione su freshness (vedremo più avanti)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Risposte
HTTP
Esempio

HTTP/version-number status-code explanation HTTP/1.1 200 OK

Header-Name-1: value Content-Type: text/html
Header-Name-2: value Content-Length: …
... …

[response body] <HTML>

<P>Benvenuti nel nostro sito!</P>
</HTML>

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Risposte
HTTP Successful response status codes (2xx)

La richiesta è stata ricevuta e servita correttamente

Informational status codes (1xx) 200 OK (dopo una GET o una POST)
201 Created (dopo una POST o una PUT)
Forniscono risposte provvisorie, ad esempio in 204 No content (dopo una POST o una PUT)
seguito all’invio di una POST parziale
100 Continue Client request error status codes (4xx)

Redirection status codes (3xx) La richiesta non è stata soddisfatta per un errore del client
400 Bad Request
La richiesta è stata ricevuta e compresa, ma sono 401 Unauthorized
necessarie altre azioni da parte dello user-agent 403 Forbidden
404 Not found
301 Moved permanently (la risorsa richiesta è stata
spostata permanentemente)
Server error status codes (5xx)
302 Found (per questa richiesta, è necessario
richiedere la risorsa alla nuova locazione) La richiesta non è stata soddisfatta per un errore del server
Un esempio di 301 è quando si richiede una cartella 500 Internal server error (solitamente un errore script)
senza indicare lo slash finale 501 Not implemented (metodo non supportato)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Header
HTTP
Gli header rappresentano i metadati dei messaggi HTTP
Essi permettono la realizzazione di funzionalità sofisticate sia pur nella semplicità di HTTP (sessioni, caching, autenticazione e
autorizzazione, business logic)

Header generali Si utilizzano sia con richieste che con risposte, ma non ne descrivono il corpo
(es. Date, MIME-Version, Transfer-Encoding, Cache-Control, Connection, Warning, …)

Date: Mon, 28 Feb 2022 08:30:00 GMT

MIME-Version: 1.0
Transfer-Encoding: … (codifica usata per la trasmissione)
Cache-Control: no-cache (gestione della cache)
Connection: close (gestione della connessione)
Warning: Fai attenzione!

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Header
HTTP
Gli header rappresentano i metadati dei messaggi HTTP
Essi permettono la realizzazione di funzionalità sofisticate sia pur nella semplicità di HTTP (sessioni, caching, autenticazione e
autorizzazione, business logic)

Header di richiesta Permettono ai client di inviare informazioni aggiuntive su se stessi e sulla richiesta
(es. User-Agent, Referer, Host, Autorization, If-Modified-Since, …)

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) (descrizione dello user agent)
Host: www.google.it (nome di dominio e porta a cui effettuare la richiesta)
Referer: https://www.poliba.it/utilities.html (pagina di provenienza)
Authorization: Basic [encoded-credentials] (gestione delle autorizzazioni)
Range: bytes=500-600,801-999 (utile ai download manager per scaricare solo parti di una risorsa)
If-Modified-Since: Mon, 25 Feb 2022 09:30:00 GMT (richieste condizionali, ad esempio per validazione cache)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: it-it (header per la content negotiation)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Header
HTTP
Gli header rappresentano i metadati dei messaggi HTTP
Essi permettono la realizzazione di funzionalità sofisticate sia pur nella semplicità di HTTP (sessioni, caching, autenticazione e
autorizzazione, business logic)

Header di risposta Aiuta il server a fornire informazioni addizionali che non si possono inferire dallo status code
(es. Location, Server, WWW-Authenticate, …)

Location: http://www.poliba.it/ (utilizzato per indicare un redirect)

WWW-Authenticate: Basic realm=“PrivateFiles” (gestione dell’autenticazione)
Server: Apache/2.2.4 (informazioni sul server)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Header
HTTP
Gli header rappresentano i metadati dei messaggi HTTP
Essi permettono la realizzazione di funzionalità sofisticate sia pur nella semplicità di HTTP (sessioni, caching, autenticazione e
autorizzazione, business logic)

Header di entità Permette di dare una descrizione del corpo del messaggio o delle risorse target (nel caso di richieste senza
corpo)

Content-Type: text/html; charset=utf-8

Content-Length: xxx
Last-Modified: Tue, 29 Apr 2008 22:28:31 GMT
Content-Encoding: …
Content-Language: …
Content-Range: …
Content-MD5: … (header utili per la decodifica e la content negotiation)
Expires: … (utile per la gestione della cache)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Content type
e content negotiation
Ricevuta la risorsa, un browser può effettuare diverse operazioni:
• presentarla come una pagina di testo o HTML
• presentare la risorsa all’interno del browser
• lanciare un’applicazione helper per presentare contenuto non HTML
• confondere il contenuto di una pagina HTML o di uno script con testo semplice e mostrarlo a schermo

HTTP deriva il sistema di tipizzazione del contenuto da Multipurpose Internet Mail Extensions (MIME)

MIME (RFC 1341, 2045-2049) è stato originariamente

pensato per fornire un meccanismo uniforme per
Gli header permettono di fornire istruzioni su come decodificare la
l’inclusione di allegati codificati in una mail risorsa inviata e su come interpretarla
MIME definisce i boundary per separare il testo dagli
allegati e le codifiche permesse per gli allegati
Content-Type: mime-type/mime-subtype
Inoltre MIME definiva una convenzione per il naming Content-Encoding: gzip, compress, deflate, br
dei tipi di file, costituita da una coppia oggetto/
formato, come per esempio text/html, text/
plain, image/jpeg, audio/mp3

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Content type
e content negotiation
Il meccanismo di content negotiation permette di servire la migliore rappresentazione di una risorsa avente differenti
varianti (es. lingua, formato, codifica)
Ogni rappresentazione ha un proprio URL, così come anche la risorsa “complessiva”

La migliore rappresentazione è scelta mediante:

• Negoziazione server-driven (o proattiva)
• Negoziazione agent-driven (o reattiva)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Content type Nella negoziazione server-driven, il browser invia,

e content negotiation insieme alla richiesta, una serie di header che

descrivono la scelta preferita dall’utente

Accept: text/html,application/
xhtml+xml,application/
xml;q=0.9,image/webp,image/apng,*/
*;q=0.8
Accept-Encoding: …
Accept-Language: …

Il server utilizza un proprio algoritmo per

determinare la migliore rappresentazione

Recentemente, la specifica Client Hints permette ai

client di inviare al server informazioni su
requirement e vincoli hardware

Questa soluzione potrebbe non scalare bene e

sollevare problemi di privacy

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Content type
e content negotiation

Nella negoziazione agent-driven, il server invia

una lista contenente i link alle risorse alternative
disponibili, così che lo user agent possa scegliere la
migliore

Non esiste un formato standard sulla lista restituita

dal server, il che impedisce l’automazione di questo
processo

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Messaggi
multipart
È possibile che il client o il server inviino messaggi
composti da più parti POST / HTTP/1.1
Content-Type: multipart/form-data;
Si tratta di un tipo di codifica in cui il client dice al boundary=---------------------------735323031399963166993862150
server (o viceversa) che il body contiene diverse parti Content-Length: 834

logiche che possono essere lette separatamente -----------------------------735323031399963166993862150

Content-Disposition: form-data; name=“casella_di_testo”

Ad esempio, è utile per trasferire file dal client al server Contenuto testuale della casella di testo
mediante richieste POST in un form -----------------------------735323031399963166993862150
Content-Disposition: form-data; name=“file_di_testo”; filename="a.txt"
Il browser applicherà un header apposito Content-Type: text/plain
Content-Type: multipart/form-data
Contenuto testuale del file a.txt
-----------------------------735323031399963166993862150
Per trasferire file tramite form, quindi, è necessario utilizzare Content-Disposition: form-data; name=“file_binario”; filename="binary"
questa strategia, indicando enctype=“multipart/form-data” Content-Type: application/octet-stream
come attributo del form
aωb
Se non ci sono file nel form, è possibile utilizzare il valore di default -----------------------------735323031399963166993862150--
enctype=“application/x-www-form-urlencoded”

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Controllo
della cache
Il caching è un insieme di meccanismi che permettono alle
risposte HTTP di rimanere temporaneamente memorizzate da Client-side caching } Caching privato
qualche parte per essere riutilizzate alla richiesta successiva, in

}
modo da: Server-side caching
• ridurre le latenze Caching condiviso
• ridurre l’overhead sulla rete Proxy-“side” caching
• ridurre il carico sul server
• migliorare le performance dell’applicazione web

Al di là dell’implementazione, le politiche di caching sono generalmente stabilite dal server o dall’applicazione web
Il server conosce la “frequenza di aggiornamento” di una risorsa e indica a browser e proxy se e per quanto tempo memorizzarla

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Controllo
della cache
Caching privato

Ciascun browser effettua, privatamente, operazioni di caching sulle risorse scaricate

Ciò permette (anche) la navigazione nella history del browser (avanti/indietro), il salvataggio, la lettura del codice sorgente,
senza necessitare di richiedere nuovamente la risorsa

Caching condiviso

Una cache condivisa memorizza risposte che possono essere riutilizzate da più di un utente
Ad esempio, un ISP o un’azienda possono avere un caching proxy nell’infrastruttura di rete che permetta di memorizzare
risorse “popolari”, in maniera che possano essere riutilizzate riducendo traffico e latenza

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Controllo
della cache

Generalmente vengono memorizzate le risposte alle richieste GET

La memorizzazione avviene usando come chiave il metodo e l’URL target, come valore la risposta, ovvero:
• La risorsa ricevuta (200 OK)
• Un redirect permanente (301 Moved Permanently)
• Un errore (404 Not Found)
• Un risultato incompleto (206 Partial Content)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Controllo
della cache
L’header che permette in HTTP/1.1 di specificare direttive sul caching di risposte è Cache-Control,
che può assumere i valori:

• no-store: la cache non deve conservare nulla né a proposito della richiesta né della risposta
• no-cache: il caching può avvenire, ma la risorsa va rivalidata prima di essere fornita all’utente
• public: la risposta può essere memorizzata da qualunque cache
• private: la risposta è pensata per un singolo utente e può essere memorizzata solo da questo
• max-age: permette di specificare (in secondi) il tempo massimo per cui una risorsa è considerata “fresca”
• must-revalidate: la cache deve rivalidare lo stato delle risorse scadute prima di usarle

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Controllo
della cache
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)
Quando la cache riceve una richiesta per una risorsa scaduta,
inoltra la richiesta al server con un particolare header per
effettuarne la sua validazione

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Controllo
della cache
Freshness

La freshness lifetime è, quindi, la “durata” di una risorsa dalla sua generazione alla sua scadenza

Essa può essere specificata mediante:

• l'header Expires con una specifica della data di scadenza, oppure
• l'attributo max-age nell'header Cache-Control con un'indicazione dei secondi di validità

Nei casi in cui né max-age né Expires siano specificati, è possibile determinare la freshness lifetime
della risorsa in maniera euristica in base alla data di ultima modifica

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Controllo
della cache
Validazione della cache

La validazione viene effettuata normalmente mediante richieste condizionali

Validazione mediante ultima modifica Validazione con ETag

Il client effettua una richiesta con l’header If-Modified- Viene utilizzata una stringa generata dal server detta ETag,
Since, specificando la data della risorsa cacheata contenuta nella risposta memorizzata, che rappresenta una
(indicata nel campo Last-Modified della risposta specifica versione della risorsa (fingerprint)
precedentemente ricevuta) L’ETag viene confrontato con quello presente sul server
Se la risorsa è stata modificata successivamente alla data mediante If-None-Match: <etag> per controllare se la
indicata, il server risponderà con un 200 OK insieme alla risorsa è in realtà ancora fresca
nuova risorsa
Se la risorsa non è stata modificata, il server risponderà
con un 304 Not Modified senza corpo

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Controllo
della cache
Validazione della cache

La risorsa non è cambiata

La risorsa è cambiata

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Controllo
della cache
Risorse revved

Vi sono risorse che possono essere conservate il più a lungo

possibile in quanto soggette raramente a cambiamenti (es. file
JS, 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
Per ottenere le nuove versioni, è necessario cambiare tutti i link
nei file che li utilizzano

Il cambiamento dei file revved, dunque, verrà effettuato

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

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
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
HTTP/1.1 200 OK
termine del trasferimento
Content-Type: text/plain
La connessione rimane attiva fino alla fine del trasferimento Transfer-Encoding: chunked
Il contenuto può essere generato “dinamicamente” durante il trasferimento
È possibile anche aggiungere header al termine, se non noti prima 4\r\n
Ciao\r\n
Transfer-Encoding: chunked (esistono anche compressed, deflate e 1\r\n
gzip) a\r\n
5\r\n
Attenzione! Questo header codifica il corpo del messaggio HTTP e non la risorsa (per
tutti\r\n
quello esiste Content-Encoding)
0\r\n
\r\n
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’
Il chunk finale è un normale chunk di lunghezza 0
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
in HTTP/1.1
Cenni su TCP

HTTP è un protocollo applicativo che si basa sul protocollo di

trasporto TCP
TCP permette di stabilire un canale di comunicazione affidabile tra
due processi applicativi di rete
Tale affidabilità, infatti, non è garantita dai livelli sottostanti dello
stack

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

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
in HTTP/1.1
Cenni su TCP

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 aperto da un processo, ovvero
una coppia indirizzo/porta solitamente nota per ciascun servizio

Chiusura di una connessione Chiusura di una connessione

Apertura di una connessione (Three-way handshake) (Doppio two-way handshake)
(Three-way handshake)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
in HTTP/1.1
Connessioni short-lived

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

cioè permettevano una singola interazione richiesta-risposta

La creazione di una connessione TCP è time- e resource-consuming

Inoltre, ogni risorsa può richiedere il download di numerose risorse
aggiuntive (una connessione per ogni risorsa)

Inoltre TCP ha capacità di controllo di flusso e congestione che non

possono essere sfruttate in connessioni così “brevi”

In HTTP/1.1 è ancora possibile utilizzare questo modello con

l’header Connection: close nelle richieste e nelle risposte

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
in HTTP/1.1
Connessioni multiple

Un workaround utilizzato è stato quello di aprire (fino a 6)

connessioni parallele verso un server

Tuttavia questo metodo:

• Crea concorrenza sull’uso della banda da parte delle varie
richieste del client (potrebbe rallentare di molto)
• Utilizza socket addizionali che consumano risorse su client e
server
• Può essere “limitato” dai server

Anche quando il tempo totale di caricamento non diminuisce,

questo approccio può dare all’utente l’impressione di un
caricamento più veloce e migliorare la UX

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
in HTTP/1.1
Connessioni persistenti

Con HTTP/1.1, una connessione persistente può rimanere aperta

per un certo periodo di tempo e riutilizzata per diverse richieste

HTTP/1.1 200 OK
Connection: Keep-Alive (valore di default)
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000

Il timeout rappresenta il numero di secondi massimo durante i

quali l’host tiene attiva una connessione “in pausa”
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

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
in HTTP/1.1
Connessioni persistenti

Un tentativo di supporto alle connessioni persistenti era già stato fatto al termine del ciclo
di vita di HTTP/1.0 con sviluppatori di server e browser che avevano introdotto l’header
“proprietario” Connection: keep-alive

Il meccanismo non era implementato da tutti gli attori coinvolti nella comunicazione, quindi
era poco efficace (es. un proxy che non supportava il meccanismo causava la chiusura della
connessione)

Oggi questo header è di default ma viene spesso inserito comunque come possibile
soluzione parziale ad attori che utilizzano ancora HTTP/1.0 ma che implementano il
supporto alle connessioni persistenti

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
in HTTP/1.1
Pipelining

La tecnica del pipelining permette di non attendere una risposta

da parte del server prima di inoltrare una nuova richiesta sulla
stessa connessione persistente

I server devono rispondere alle richieste in ordine di arrivo

Si suppone che i server “supportino” questa tecnica o che almeno
non generino errori

Solo metodi idempotenti possono utilizzare il pipelining

Oggi la maggior parte dei browser non supporta (almeno di default) il pipelining a causa di:
• Possibili proxy che non lo supportano (possono decidere di bloccare la connessione o serializzare le richieste)
• Difficoltà nell’implementazione delle diverse casistische
• Code di richieste bloccate da richieste precedenti “primarie” (head-of-line blocking)
• Una richiesta fallita può terminare la connessione e forzare a rifare tutte le richieste successive
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
in HTTP/1.1
Pipelining

In assenza di multiplexing che permetta un interleaving delle risposte, e dovendo scongiurare rischi di saturazione delle risorse
dei server e di rielaborazioni in caso di errori, nemmeno la parallellizzazione dell’elaborazione può aiutare

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Esercizi
Esercizio 2.1

Si supponga di voler ottenere una pagina web di lunghezza Lp = 500 kbit che contiene 5 immagini di lunghezza Li =
100kbit ciascuna
La pagina e le immagini sono memorizzate tutte sullo stesso server che ha un RTT di 250 ms dal browser
Si supponga, inoltre, che il collegamento astratto fra il browser e il server ha una capacità C = 100 Mbps
Le richieste GET hanno tutte una dimensione irrilevante e il tempo di elaborazione sul server è trascurabile

Qual è il tempo di risposta (tempo che intercorre fra la richiesta della pagina e il ricevimento di tutte le risposte) nei
seguenti casi?

1. Connessione HTTP non persistente senza possibilità di utilizzare connessioni parallele

2. Connessione HTTP non persistente con possibilità di utilizzare fino a 6 connessioni parallele
3. Connessione HTTP persistente senza possibilità di utilizzare il pipelining
4. Connessione HTTP persistente con possibilità di utilizzare il pipelining

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Esercizi
Esercizio 2.2

Un’organizzazione possiede una LAN con un proxy HTTP di caching

I client della LAN sono connessi al proxy con una connessione ad alta velocità dedicata avente capacità Ccp = 1 Gbps
La probabilità che un documento sia presente all’interno della cache è pari a p=0.4
Si assuma che:
• I messaggi di richiesta HTTP abbiano dimensione Lg = 100 bit
• I messaggi di risposta senza corpo abbiano dimensione Ls = 100 bit
• Si vuole ottenere una risorsa di dimensione Lp = 100 kbit
• Il proxy HTTP ha un collegamento di capacità Cps = 100 Mbps con l’origin server
• Il RTT è pari a 250 ms

Si calcoli il tempo di risposta medio per un generico client della LAN nell’ottenimento della risorsa nei seguenti casi:
• La risorsa contiene un header Cache-Control: must-revalidate e non è scaduta
• La risorsa contiene un header Cache-Control: must-revalidate ed è scaduta (sul server non è cambiata)
• La risorsa contiene un header Cache-Control: must-revalidate ed è scaduta (sul server è cambiata)
• La risorsa contiene un header Cache-Control: no-cache ed è scaduta (sul server non è cambiata/è cambiata)
• La risorsa contiene un header Cache-Control: no-cache e non è scaduta (sul server non è cambiata/è cambiata)
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Virtual
hosting
Introdotto con HTTP/1.1, permette che richieste a diversi nomi di dominio siano indirizzate (eventualmente a diversi siti)
su uno stesso web server

Virtual hosting basato su IP

Ogni nome punta a diversi indirizzi IP attivi sullo stesso web server
(O a diverse porte di uno specifico IP di un web server)
Ogni applicazione è in ascolto su un IP/porta specifico
Utilizzabile anche con HTTP/1.0 e HTTPS

Virtual hosting basato su 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

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Meccanismi di
autenticazione
HTTP definisce in RFC 7235 un framework di autenticazione per la verifica dell’identità dell’utente e la sua autorizzazione
ad accedere a una particolare risorsa

1 Se la risorsa richiesta prevede autorizzazione, il server invia un messaggio di non autorizzazione con indicazioni su come
effettuare l’autenticazione
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm=“PrivateFiles” (schema/realm)
Il realm identifica in maniera logica quali risorse richiedono determinate autorizzazioni
2 Il browser chiede all’utente username e password associate al realm specificato
GET /files/
Host: www.poliba.it
Authorization: Basic eNCoDed-uSErId:pASwORd

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

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Meccanismi di
autenticazione

Con lo schema basic username e password sono in una stringa codificata con base64 e reversibile (non crittografata)
Può essere uno schema sicuro solo su una connessione sicura

Vi sono altri schemi che possono differire per sicurezza e per disponibilità su software server e client

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

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Supporto
alle sessioni
Come abbiamo detto, HTTP è un protocollo stateless
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

Grazie alle sessioni, le applicazioni web sono capaci di:

• Mantenere il login dell’utente
• Conservare lo stato del carrello di un e-commerce
• Personalizzare l’esperienza dell’utente durante la navigazione ricordandone le scelte (es. quanti risultati per pagina
mostrare)
• Tracciare un profilo di navigazione dell’utente (che corrisponde alle sue abitudini)

Per far ciò è necessario trasferire informazioni di stato all’interno dei messaggi HTTP

Una tecnica largamente utilizzata è quella dei cookie, piccoli pezzi di dati che un server invia a un browser, e che il
browser invia al server nelle richieste successive

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Supporto
alle sessioni
Impostazione di un cookie

Set-Cookie: <name>=<value>
[; Max-Age=<value>] [; Expires=<date>]
[; Path=<path>] [; Domain=<domain name>]
[; Secure] [; HTTPOnly]

Set-Cookie permette al server di impostare sul client informazioni di stato oppure un identificatore di sessione che
referenzia uno stato server-side

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” (indefinito)

Domain può essere impostato a un suffisso dell’host di origine, es. l’host sisinflab.poliba.it può impostare Domain a
poliba.it, in modo che il cookie valga per tutti gli host del tipo *.poliba.it
Domini esterni o sottodomini del dominio corrente vengono rigettati dagli user-agent

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Supporto
alle sessioni
Uso di un cookie

Ricevuto un cookie, i client devono provvedere alla sua memorizzazione

Successivamente, essi utilizzeranno l’header Cookie nelle richieste successive allo stesso server (o a server
collegati) tali che che vi sia corrispondenza di dominio, percorso e porta e invieranno tutti i cookie corrispondenti

Cookie: <name>=<value>

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Supporto
alle sessioni
Cookie first-party e third-party

Quando il cookie è creato dal sito stesso che l'utente sta visitando, esso è
considerato first-party
I cookie first-party svolgono ruoli come:
• ricordare le preferenze dell'utente
• facilitare esperienza dell'utente

Tuttavia una pagina web può incorporare elementi provenienti da altri domini
(es. ads o tool di analitica), i quali potranno impostare cookie third-party
I cookie first-party svolgono generalmente ruoli di advertising e tracking

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Supporto
alle sessioni
Cookie first-party e third-party

Notiamo che “third-party” assume significato nel contesto dell’utente, in base

al sito che sta visitando: non si tratta di un concetto assoluto
Se il nostro sito imposta un cookie show_promo per decidere se mostrare o
meno una promozione, se qualcuno inserisce una nostra immagine nel suo
sito, il cookie continuerà ad essere inviato come third-party cookie

Il cookie show_promo non ha motivo di esistere come cookie di terze parti

Esso ha un effetto non intenzionale

Invece, un cookie di terze parti di YouTube che ci permette di salvare per

guardare più tardi un video incorporato in un altro sito ha un effetto
intenzionale ed utile nella navigazione di altri siti

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
 Supporto
alle sessioni
Cookie first-party e third-party

Ad esempio, è possibile inserire un adv personalizzato in base alla history di

navigazione dell'utente e informazioni demografiche
È sufficiente utilizzare i tracking cookie di terze parti di una ad platform condivisa
fra vari siti web e capace di tracciare la history di navigazione dell'utente

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Supporto
alle sessioni
Cookie first-party e third-party

L’attributo SameSite permette di definire il contesto in cui un cookie può

essere utilizzato

Set-Cookie: show_promo=1; SameSite=Strict

Permette di utilizzare un cookie esclusivamente in un contesto first-party, e
con richieste iniziate esclusivamente all’interno dello stesso sito

Set-Cookie: show_promo=1; SameSite=Lax

È il valore di default, può essere utilizzato solo in un contesto first-party ma è
inviato anche quando un utente naviga verso l’origin site dall’esterno

Set-Cookie: show_promo=1; SameSite=None; Secure

Permette di utilizzare il cookie anche in un contesto third-party e con richieste
cross-origin ma deve essere utilizzato con Secure

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Supporto
alle sessioni
Cookie e privacy

I cookie di terze parti sono largamente utilizzati a fini di tracciamento delle preferenze e delle abitudini degli utenti
Alcuni browser oggi bloccano automaticamente cookie di terze parti che fungono da tracker

Inoltre alcune leggi, come il GDPR in Europa o il CCPA in California, regolano questo aspetto richiedendo che:

• Gli utenti siano informati sull’utilizzo di cookie

• Gli utenti possano scegliere di non ricevere tutti o alcuni cookie
• Gli utenti possano usare i servizi principali di un sito senza ricevere cookie

I cookie banner permettono agli sviluppatori di comprendere e adeguarsi alle più recenti normative di ciascun Paese
I Cookiebot permettono di verificare la conformità del proprio sito

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Supporto
alle sessioni
Cookie e sicurezza

Alcuni parametri permettono di mitigare alcune falle di sicurezza che si possono verificare con l’uso dei cookie

Secure permette di inviare il cookie solo su richieste crittografate (HTTPS) limitando attacchi man-in-the-middle

Per limitare attacchi del tipo cross-site request

L’utente A si è autenticato al sito www.mybank.it per l'accesso alle
forgery (CSRF) come nell’esempio a destra è
operazioni sul suo conto bancario. Il sito ha un form per i versamenti che
necessario: effettua una GET a www.mybank.it/versamento?
• usare le GET con azioni idempotenti importo=XXXX&destinatario=XXXX. Un attaccante M, mediante il suo
• utilizzare dei token CSRF all’interno di cookie da sito, mostra ad A un’immagine fittizia <img src='www.mybank.it/
inviare insieme alle POST versamento?importo=1000E&destinatario=M'>. Di fatto, il browser

• usare SameSite=Strict fra i valori di Set- invierà una richiesta HTTP alla pagina web indicata cercando di caricare
l’immagine. Il sito www.mybank.it rileverà, tramite il cookie ancora attivo,
Cookie per non permettere ai cookie di essere
che la richiesta arriva effettivamente da A e perciò autorizzerà l’operazione.
inviati in richieste cross-site
Similmente, è possibile attivare una POST mediante un form invisibile inviato
• usare l’attributo HTTPOnly per evitare che “di nascosto” via JavaScript.
JavaScript possa accedere ai cookie
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Supporto
alle sessioni
Cookie e sicurezza

Un altro problema legato ai cookie è quello del session fixation

• L’utente A effettua l’accesso su www.mybank.it, ma Per evitare questo attacco è necessario effettuare alcune scelte:
l’utente M riesce a rubargli il session ID nei cookie,
• Evitare di poter impostare cookie tramite query string (immaginate
ottenendo quindi accesso all’account di A.
in quanti posti vengono memorizzati/copiati gli URL che visitiamo)
• L’utente M genera un session ID o fa sì che il server
generi un session ID, quindi lo invia all’utente A (ad es. • Chiedere all’utente di rieffettuare il login (e contestualmente
in un link www.mybank.it/?s_id=XXX). L’utente A cambiare il session ID) per operazioni importanti
effettua l’accesso e a questo punto M avrà associato il • Accettare solo session ID generati dal server
session ID al login di A. • Rigenerare il session ID a ogni richiesta
• Un utente malevolo M gestisce il sottodominio
• Verificare consistenza dello user-agent fra le diverse operazioni
evil.mybank.it e porta A a visitarlo impostando un
• Utilizzare la strategia del token CSRF
cookie per .mybank.it sul browser di A. Se l’utente A
effettua l’accesso con quel cookie, M avrà quindi
accesso alla sessione di A.

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
sicure
L’uso del protocollo TLS (Transport Layer Security) su una connessione TCP permette di
criptare i flussi di dati fra i due endpoint

Un osservatore esterno:
• Può inferire i due endpoint della connessione
• Può inferire il tipo di crittografia
• Può inferire la frequenza e una stima della quantità di dati scambiati
• Non può leggere o modificare l’informazione scambiata

Questa soluzione permette di non dover cambiare il protocollo a livello applicativo (come
proposto con S-HTTP), ma di affidarsi direttamente ad una infrastruttura di trasporto sicura

TLS garantisce servizi di crittografia, autenticazione e integrità

Quando HTTP utilizza TLS, permettendo quindi lo scambio sicuro di messaggi, prende il nome
di HTTPS
HTTPS protegge l’integrità del sito web, la privacy e la sicurezza degli utenti

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
sicure I due endpoint stabiliscono la suite di cifratura:
• Algoritmo di scambio delle chiavi (eseguito mediante
handshake)
• Tipo e modalità di cifratura dei dati
• Algoritmo di Message Authentication Code per la verifica
di integrità e autenticità del messaggio

In particolare, in ClientHello, il client invia al server la lista

di suite di cifratura supportate
Il server sceglie la suite e risponde con il proprio
certificato
Il client verifica il certificato e inizia lo scambio di chiavi
Ad esempio, con l’algoritmo RSA, il client genera una chiave
simmetrica, poi cifra la propria chiave con la chiave
pubblica del server
Il server quindi usa la propria chiave privata per trovare la
chiave simmetrica del client
Da questo momento i due endpoint useranno la chiave
simmetrica per le loro comunicazioni
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
sicure
I meccanismi di autenticazione di HTTPS, che permettono di sapere di star parlando con la "persona" giusta, si basano sui
certificati

Si consideri il seguente esempio:

• A e B generano le loro chiavi private e pubbliche
• A e B condividono le loro chiavi pubbliche ⚠
• A genera un messaggio per B e lo cifra con la sua chiave privata
• B decifra il messaggio con la chiave pubblica di A e verifica, quindi, che il messaggio proviene effettivamente da A

Ma siamo sicuri che A e B fossero effettivamente loro?

O meglio, quando B decifra il messaggio di A con la chiave pubblica di A, può essere certo che quella chiave pubblica fosse
proprio di A e non di qualcun altro che si sta spacciando per A?
Dobbiamo supporre che esista una certa "fiducia" fra A e B per cui essi sono sicuri che le chiavi pubbliche che si sono
scambiati siano proprio le loro e che non ci fosse alcun impostore di mezzo

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
sicure
Si supponga ora che A vuole comunicare con C, che non ha
mai incontrato e che dice di essere amico di B
Per dimostrare di essere amico di B:
• C ha dato a B la propria chiave pubblica e gli ha chiesto di
firmarla con la sua chiave privata
• C parla con A includendogli questa firma
• Poiché A conosce la chiave pubblica di B e si fida di
questa, può verificare che effettivamente B ha firmato la
chiave di C
• A usa la chiave pubblica di C per verificare di star parlando
proprio con C

In questa maniera si è creata una catena di fiducia: A si fida di B, B si fida di C, quindi A decide di fidarsi di C

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Connessioni
sicure Allo stesso modo funziona il processo di
autenticazione all’interno del Web

Vi è una lista predefinita di Certificate Authorities

fidate, che può essere estesa aggiungendo
manualmente certificati

Le Certificate Authorities si fanno carico di verificare

e garantire la corrispondenza fra chiave pubblica e
proprietario

Attraverso l’uso di una catena di fiducia transitiva,

il browser può quindi verificare l’attendibilità di un
sito web
In particolare, nel processo di validazione il browser
verifica che tutto l'albero delle CA collegate al
certificato fornito dal sito sia fidato

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Il passaggio ad
HTTP/2.0
HTTP/1.1 ha rappresentato la base per l’enorme crescita del Web e di Internet
Come abbiamo visto, un semplice protocollo testuale per il reperimento di ipertesti si è evoluto diventando lo standard per il
trasporto di qualunque ipermedia per soddisfare (praticamente) qualunque caso d’uso

Tuttavia, una serie di necessità/obiettivi hanno portato alla definizione di HTTP/2.0, che quindi offre:
• Miglioramento delle performance
• Riduzione delle latenze con l’introduzione del multiplexing di richieste e risposte (HTTP/1.1 doveva utilizzare le connessioni
multiple)
• Minimizzazione dell’overhead del protocollo dovuto agli header non compressi
• Supporto per priorità delle richieste
• Supporto per server push

HTTP/2.0 è un protocollo:
• Che lavora meglio con la rete sottostante, in quanto richiede meno connessioni TCP
• Che crea meno competizioni con altri flussi di rete
• Che utilizza connessioni più lunghe (e che usano meglio le capacità della rete)
• Che permette una migliore elaborazione dei messaggi grazie all’introduzione di frame binari
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Il passaggio ad
HTTP/2.0
HTTP/2.0 è nato in seguito alle evoluzioni del protocollo SPDY di Google, che aveva come obiettivi:
• Ridurre del 50% del tempo di caricamento delle pagine web
• Evitare cambiamenti da parte degli sviluppatori di siti web
• Minimizzare le difficoltà di deployment, evitando cambi infrastrutturali

Nel 2012 l’HTTP Working Group, a partire dalle idee di SPDY, che stavano riscuotendo un buon successo in web server e
browser popolari, ha iniziato a sviluppare lo standard HTTP/2.0
La definizione di HTTP/2.0 e l’evoluzione SPDY sono continuate parallelamente supportandosi a vicenda
Nel 2015, con gli RFC 7540 e 7541, HTTP/2.0 è stato pubblicato come standard
Poco dopo, lo sviluppo di SPDY è stato abbandonato

HTTP/2.0 è stato introdotto senza modificare la semantica di HTTP/1.1:

• Metodi, codici di stato, URI e header vengono preservati in HTTP/2.0
• Non sono richieste modifiche da parte degli sviluppatori web
• Solo gli sviluppatori a livello più basso rilevano delle differenze

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Elementi
di HTTP/2.0
HTTP/2.0 cambia il concetto classico di trasmissione di messaggi
plaintext fra server e client
Le comunicazioni fra client e server diventano, infatti, flussi di dati
binari

Questa caratteristica rappresenta la base di tutte le altre feature di

HTTP/2.0

In particolare, in HTTP/2.0, i messaggi fra client e server vengono

suddivisi in frame binari più piccoli

HTTP/2.0 definisce in
RFC 7541 lo standard
HPACK per la compre
ssione degli header

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Elementi
di HTTP/2.0
I frame rappresentano l’unità di informazione elementare
Possono essere di vari tipi (es. HEADERS, DATA, …)
Sono costituiti da un header e una sequenza di byte variabile

Ogni frame è mappato ad uno specifico messaggio “logico” di

HTTP, che è quindi composto da uno o più frame

Uno o più messaggi (in entrambe le direzioni) compongono uno

stream (es. richiesta e risposta)
Ogni stream ha un ID unico e informazioni opzionali di priorità
Frame da stream differenti possono viaggiare in maniera
interleaved ed essere riassemblati grazie allo stream ID

Su un’unica connessione TCP possono quindi viaggiare più

stream

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Multiplexing
in HTTP/2.0
HTTP/2.0 permette di rimuovere i workaround visti in HTTP/1.1 per velocizzare la consegna di messaggi (es. pipelining,
parallellizzazione dell’elaborazione, connessioni multiple, …)
Questi meccanismi, infatti, non utilizzavano a pieno le potenzialità di TCP, potevano avere problemi di head-of-line blocking e
potevano facilmente esaurire le risorse di client e server

HTTP/2.0 permette di effettuare il multiplexing di frame di

diversi stream su una stessa connessione

• Ciascun messaggio non è bloccante per gli altri (è

eliminato il problema di head-of-line blocking)
• Non sono necessarie connessioni parallele ma una sola
connessione per origine
• Vengono utilizzate a pieno le potenzialità di TCP
(ottimizzato per connessioni più lunghe)
• Non sono necessari workaround come domain sharding,
file concatenati e image sprite
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Priorità degli stream
in HTTP/2.0
HTTP/2.0 permette ai browser di specificare con quale priorità (peso) intende ricevere determinati stream di risposta e se
esistono eventuali dipendenze fra essi
Dal punto di vista del server, il peso di ciascuno stream rappresenterà la proporzione di risorse con cui esso sarà processato

Per accelerare il caricamento di una pagina, i client

specificano la priorità principalmente in base al tipo di file
che stanno richiedendo (HTML, CSS, JS per primi, poi altre
risorse e immagini), in base alla posizione nella pagina o in
base a priorità apprese da visite precedenti

Va sottolineato che l’albero di priorità esprime una

preferenza del client, ma non è in nessun modo un
“obbligo” per il server rispettarlo (in questo modo si evitano
head-of-line blocking, etc.)

Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Server push
in HTTP/2.0
HTTP/2.0 rompe la semantica rigida del paradigma richiesta-risposta e permette di al server di inviare più risposte per una
singola richiesta del client
Questo meccanismo permette di inviare tutte le risorse associate ad un documento richiesto dal client, senza che il client
debba prima scoprirne la necessità e richiederle esplicitamente

Prima di HTTP/2.0, una strategia per evitare che i client richiedessero le risorse aggiuntive fornendole in maniera “proattiva”
era quella di incorporarle nel file principale
Con il server push, però, le risorse possono essere inviate all’interno di stream in un multiplex, possono essere cachate,
riutilizzate oppure anche rifiutate da un client

La strategia prevede che i server inviino dei frame di tipo

PUSH_PROMISE per segnalare l’intenzione di fare push di
alcune risorse (il client può rifiutare con un frame
RST_STREAM)
È importante che questi frame vengano inviati prima di quelli
relativi al documento in cui le risorse aggiuntive sono
referenziate, per evitare che il client le richieda
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)
Usare
HTTP/2.0
Nel mondo vi sono milioni di server e miliardi di client, pertanto il passaggio ad HTTP/2.0 non è immediato
I moderni browser già supportano questa versione di HTTP (ma alcuni utenti potrebbero tardare negli aggiornamenti), mentre
l’aggiornamento di server e dispositivi intermedi è un processo più lungo

Pertanto, se un client HTTP/2.0 non ha previa conoscenza di un server, essi devono essere capaci di negoziare sulla versione
del protocollo da utilizzare
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Il server accetta
Upgrade: h2c *
GET /page HTTP/1.1 l’upgrade
Host: server.example.com
[risposta HTTP/2]
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c *
HTTP2-Settings: [SETTINGS payload] HTTP/1.1 200 OK
Il server non Content-length: 243
accetta l’upgrade Content-type: text/html
*h2c è sostituito con h2 nel caso di
connessioni sicure
[risposta HTTP/1.1]
Antonio Ferrara | Fondamenti del Web (Ingegneria del Software e Fondamenti Web)