Il protocollo http
1
Web

Una pagina web è formata da oggetti.

Gli oggetti possono essere file HTML, immagini (JPEG, GIF,
PNG), applet Java, file audio,…

Ogni oggetto è identificato da un URL.
2
HTTP
3
HTTP

HTTP si appoggia a TCP.

Il client HTTP (il browser) inizia una connessione TCP sulla
porta 80 del server.

Il server HTTP (Web server) accetta la connessione TCP del
client.

Client e server si scambiano messaggi HTTP (attraverso le
socket).

Si chiude la connessione TCP.
4
HTTP

HTTP
è
“stateless”:
il
server
non
mantiene
alcuna
informazione sulle richieste dei vari client.
I protocolli che mantengono lo stato sono complessi. Si deve
mantenere traccia della storia passata perché, se il server o
il client si guastano, la loro visione dello stato può diventare
inconsistente e deve essere ripristinata.
5
Caratteristiche del protocollo HTTP

Application level
•

Utilizza TCP.
Request/Response
•
Quando la connessione è stata stabilita il browser invia una richiesta HTTP a cui il
server risponde.


Stateless
•
Ogni richiesta HTTP contiene tutte le informazioni per essere servita.
•
Il server non tiene traccia delle informazioni precedenti.
Trasferimento bidirezionale
•
Nella maggioranza dei casi il browser invia una richiesta di una pagina web e il
server invia una copia della pagina richiesta al browser.
•
HTTP consente anche trasferimenti dal browser al server (quando un utente invia
una form).
6
Caratteristiche del protocollo HTTP

Capacità di negoziazione
• HTTP consente al browser e al server di negoziare aspetti quali ad
esempio il set di caratteri usato. Una delle parti può specificare le
capabilities che può offrire e l’altra parte può specificare le capabilities
che può accettare.

Supporto per il caching
• Per migliorare i tempi di risposta un browser memorizza in cache una
copia di ogni pagina web che riceve. Se l’utente richiede una pagina
precedentemente richiesta, HTTP permette al browser di interrogare il
server per determinare se i contenuti della pagina sono cambiati.

Supporto per intermediari
• HTTP consente di avere degli agenti intermedi nel percorso tra browser
e server (proxy). I proxy possono avere dei meccanismi di caching.
7
HyperText Transfer Protocol - HTTP

La natura stateless di HTTP si adatta bene al suo uso tipico
• Una normale sessione di un utente di un browser web comporta il
recupero di una sequenza di pagine e documenti web.
• Questa sequenza (idealmente) deve essere acquisita in modo veloce
anche se le pagine e i documenti possono risiedere in più sistemi
distribuiti su rete geografica.

HTTP è flessibile nei formati che può trattare
• Quando un client inoltra una richiesta ad un server, può includere una
lista di formati che può gestire, ordinata secondo dei livelli di priorità,
ed il server può rispondere con il formato più appropriato.

es.: un interprete lynx non può gestire immagini, pertanto un server web
non ha bisogno di trasmettere le immagini contenute nelle pagine (non si
trasmettono informazioni inutili).
8
HTTP – Esempio di operazioni

Lo user agent è il client che genera la richiesta (browser
web).

L’origin server è quello in cui risiede la risorsa richiesta
(pagina).

Il client apre una connessione TCP end-to-end tra se stesso
ed il server ed inoltra una richiesta HTTP.
• Questa richiesta è costituita da uno specifico comando (metodo),
da una URL ed un messaggio simile a quelli MIME che contiene
alcuni parametri di richiesta, delle informazioni sul client e
talvolta alcune informazioni sul contenuto.
9
HTTP – Esempio di operazioni

Quando il server riceve la richiesta, tenta di eseguire il
recupero della pagina richiesta ed invia una risposta HTTP,
che include informazioni sullo stato, un codice che indica il
successo o riporta errori avvenuti e un messaggio dalle
caratteristiche simili a quelle di MIME, contenente delle
informazioni
relative
al
server,
alla
risposta
stessa
e
all’eventuale contenuto del body del messaggio.

La connessione TCP viene chiusa.
10
HTTP – Esempio di operazioni

In questo caso non vi è una connessione TCP end-to-end tra lo user
agent e il server. Sono presenti uno o più sistemi intermediari e delle
connessioni TCP tra sistemi “adiacenti”.

Il protocollo HTTP definisce tre tipi di sistemi intermediari:
•
Proxy
•
Gateway
•
tunnel
11
HTTP – Proxy

Un proxy agisce per conto di altri client e inoltra le richieste ad un server, opera
come server nei confronti dei client e come client nei confronti del server.

Intermediario di sicurezza: client e server separati da un firewall.
•
Il client fa parte di una rete resa sicura da un firewall ed il server è esterno a questa
rete.
•
Il server deve autenticarsi con il firewall per stabilire una connessione con il proxy che
accetta le risposte dopo che queste sono passate attraverso il sistema di sicurezza.

Versioni diverse di HTTP: il proxy può interpretare entrambe le versioni ed
effettuare le conversioni.

Il proxy è un agente che riceve una richiesta per un oggetto (identificato da una
URL), la modifica e la inoltra verso il server identificato dalla URL.
12
Proxy server: web cache

Permette di migliorare le prestazioni dell’accesso ad Internet
soddisfacendo, quando possibile, le richieste dei vari client al
posto dei server remoti.
13
Proxy server: IP masking

Inoltre, permette di rendere pubblico all’esterno un solo indirizzo
IP, quello del proxy.
14
Proxy server: access control

Infine, può anche essere usato per controllare l’accesso alle
risorse.
15
HTTP – Gateway

Un gateway è un server che appare al client come se fosse il server d’origine, ed
agisce per conto del server o di server che potrebbero non essere in grado di
comunicare direttamente con il client.

Server non-HTTP: i browser possono contattare dei server con protocolli
diversi (FTP, ecc.). Questa capacità può essere fornita mediante un gateway.
•
Il client invia una richiesta HTTP verso il server gateway e quest’ultimo contatta il server
FTP per ottenere il risultato desiderato, che poi viene convertito in una forma adatta ad
HTTP ed inviato al client.

Intermediario di sicurezza: client e server separati da un firewall rispetto al
quale il gateway si trova sullo stesso lato del server.
•
Il server è all’interno di una rete protetta tramite un firewall ed il client è esterno a tale
rete.
•
Il client si deve autenticare al gateway il quale può passare la richiesta al server.
16
HTTP – Tunnel

Un tunnel, a differenza del proxy e del gateway, non opera sulle
richieste/risposte HTTP.

Un tunnel è un punto di collegamento fra due connessioni TCP ed i
messaggi HTTP vengono trasmessi inalterati come se ci fosse una
singola connessione HTTP fra client e server.
•

Non è necessario che questo sistema interpreti i contenuti dei messaggi.
Un esempio è quello di un firewall, in cui un client o un server, esterni
ad una rete protetta, vogliono stabilire una connessione, mantenerla
ed usarla per transazioni HTTP.
17
Uniform Resource Locator (URL)

Ad ogni pagina web è assegnato un nome unico usato per identificare
la pagina, la URL.

La URL inizia con la specifica dello scheme utilizzato per accedere
all’elemento di informazione (pagina).

Lo schema specifica il protocollo usato.
http://hostname[:port]/path[?query]

hostname specifica il nome a domini o indirizzo IP dell’host;

:port è un parametro opzionale richiesto solo se il numero di porta del server è
diverso da 80;

path è una stringa che identifica un particolare documento;

?query è una stringa opzionale utilizzata quando il browser invia una query.
18
Struttura di una transazione HTTP
19
Connessioni HTTP
HTTP/1.0 [RFC 1945]
HTTP/1.1 [RFC 2616]
Su ogni connessione TCP si
invia al più un oggetto.
Più oggetti possono essere
inviati sulla stessa connessione
TCP.
Connessione NON persistente.
Permette una connessione
persistente.
20
HTTP non persistente
Supponiamo che l’utente digiti
l’indirizzo
www.nomedip.nomeuni.it/index.html e
che il file contenga 10 immagini.
1. Il client HTTP inizia una
connessione TCP sulla porta
80 del server (il processo
server) all’indirizzo
www.nomedip.nomeuni.it
2. Il server HTTP, in attesa di
connessioni TCP sulla porta
80, “accetta” la connessione e
manda una notifica al client
21
HTTP non persistente
3. Il client HTTP manda una
richiesta HTTP (request
message) che contiene una
URL
Il messaggio indica che il
client richiede la pagina
index.html
4. Il server HTTP riceve la
richiesta, forma un messaggio
di risposta (response
message) che contiene
l’oggetto richiesto e lo inoltra
22
al client
HTTP non persistente
5. Il server HTTP chiede la
chiusura della connessione
TCP
6. Il client HTTP riceve il
messaggio di risposta che
contiene il file index.html.
Comincia a visualizzarlo e
durante la parsificazione si
accorge che ci sono 10
riferimenti ad oggetti JPEG
I passi 1-6 vengono ripetuti
per ogni oggetto JPEG.
23
HTTP non persistente
24
HTTP non persistente

Richiede due RTT per trasferire ogni oggetto
(più il tempo per il trasferimento effettivo del file).

Il S.O. deve allocare le risorse per ogni
connessione TCP.

I
browser
spesso
possono
aprire
più
connessioni TCP in parallelo per caricare gli
oggetti inclusi in un file html.
25
HTTP persistente

Il server non chiude la connessione TCP dopo
aver inviato una risposta.

I messaggi HTTP successivi (tra lo stesso
client e lo stesso server) vengono inoltrati
sulla connessione aperta.

Il tempo di trasmissione diminuisce.
26
HTTP persistente

Senza pipelining
• Il client invia una nuova richiesta solo quando ha ricevuto la
risposta precedente.
• Tempo richiesto: un RTT per ogni oggetto.

Con pipelining
• Default nella versione HTTP/1.1.
• Il client invia una nuova richiesta non appena incontra un
riferimento ad un oggetto durante la parsificazione di un file
html.
27
HTTP persistente
28
HTTP request: formato
29
HTTP request: formato
30
Metodi
HTTP 1.0
HTTP 1.1
• GET
•
GET, POST, HEAD
• POST
•
PUT
• HEAD

Restituisce solo l’header.

•
File upload sul server.
DELETE

Per cancellare i file sul server.
31
HTTP response: formato
32
Struttura di una transazione HTTP

Le transazioni HTTP non necessariamente usano tutti gli headers.
• Es.: la richiesta GET / HTTP/1.0 (senza headers aggiuntivi) può
essere sufficiente.
GET / HTTP/1.1
Connection: Keep-Alive
Referer: http://www.dsi.unifi.it/~ferrari/pippo.html
User-Agent:Mozilla/3.0Gold (WinNT)
Host: www.dsi.unifi.it
Accept: image/gif image/x-xbitmap, image.jpeg
Content-type: application/x-www-form-urlencoded
Content-length: 23
In questo caso vuoto
33
Struttura di una transazione HTTP

Componenti delle requests
• La prima linea denota quale metodo il client vuole usare, su quale
documento si vuole applicare il metodo e la versione HTTP.

HTTP/1.1 definisce i metodi GET, POST, HEAD, PUT, LINK, UNLINK, DELETE,
OPTIONS, TRACE.
• La URL specifica la locazione del documento. Ogni server può utilizzare
meccanismi diversi per tradurre la URL in una forma di indirizzamento per
la risorsa richiesta. A volte la URL indica un programma che genera
dinamicamente il contenuto da inviare al client (pagine dinamiche).

I General-header sono header opzionali utilizzati sia nelle client
request
che
nelle
server
response.
Indicano
informazioni
sulla
connessione oppure current-time.
34
Struttura di una transazione HTTP

Request
headers
sono
headers
che
inviano
al
server
informazioni sul client.
• Possono identificare l’agente utilizzato.
• Specificano i formati accettati.

Entity headers vengono utilizzati quando un documento viene
spedito e specificano informazioni sul documento.
• Encoding scheme.
• Lunghezza.
• Tipo.
35
Struttura di una transazione HTTP
HTTP/1.0 200 OK
Date: …
Server: Apache/1.1.1
Content-type: text/html
Content-length: 327
Last-modified …
<title> … </title>
….
36
Metodi del client - GET

Possiamo considerare i metodi come delle dichiarazioni delle intenzioni
del client.

Il metodo GET serve ad inviare al server una richiesta per ottenere una
risorsa (file oppure richiamare l’esecuzione di un programma che
produce un output per il client).

Il server risponde ad una GET con una status line, degli headers ed
(eventualmente) i dati richiesti dal client.
37
Metodi del client - HEAD

Il metodo HEAD si comporta in modo simile al metodo GET, con la
differenza che il server in questo caso non invia il body.

Questo metodo viene spesso utilizzato dal client per verificare
l’esistenza di un documento oppure per conoscere Content-length o
Content-type.

Utilizzi
• Tempo dell’ultima modifica per utilizzo del caching.
• Lunghezza del documento per stimare tempi di arrivo, oppure per scegliere
documenti di dimensioni inferiori.
• Content-type per permettere al client di esaminare solo certi tipi di
documenti.
• Informazioni sul tipo di server per effettuare certi tipi di queries.

38
Alcuni headers sono opzionali e quindi alcuni server non li forniscono.
POST (dati inviati al server)

Il metodo POST permette al client di specificare dati da inviare ad un
qualche programma a cui il server può accedere.

Esempi di utilizzo
• Programmi CGI.
• Gateways verso servizi di rete, server NTTP (per le news).
• Interfaccia per inviare dati a qualche programma.
• Operazioni su basi di dati.

In una POST request i dati vengono inseriti nella entity-body.

Dopo che il server ha esaminato gli headers può passare la entitybody ad un altro programma (specificato nella URL).

Una POST request ha un header Content-type che descrive il formato
della entity-body.
39
HTTP response: status code

200 OK

301 Moved permanently

400 Bad Request

404 Not Found

505 HTTP Version Not Supported

…
40
HTTP response ???
telnet www.educ.di.unito.it 80
GET / HTTP/1.1
Host: www.educ.unito.it
Dopo aver digitato due volte il tasto Enter (Invio) si apre una
connessione TCP alla porta 80 del server
www.educ.di.unito.it
Poi viene inviato il comando GET e il server risponde…
41
HTTP response !!!
42
HTTP: un esempio (cont)

Comando HTTP GET /
•
Il server restituisce tutto il documento (la home page).
•
La linea finale dell’output del client telnet indica che il server ha chiuso la connessione
TCP dopo aver scritto l’ultima linea dell’output.

Un documento HTML inizia con <HTML> e termina con </HTML> (molti
comandi HTML sono appaiati secondo questo schema).
•

il documento contiene una head e un body.

Head delimitata da <HEAD> e </HEAD>.

Body delimitato da <BODY> e </BODY>.
La linea
<CENTER><IMG ALIGN=center SRC= “/icons/uni_logo2.gif” >
specifica un’immagine.
43
HTTP: un esempio (cont)

Quando il server invia questa home page non viene inviato il file
immagine (HTTP 1.0). Viene inviato solo il nome del file, il client deve
aprire un’altra connessione TCP verso il server per prelevare questo
file.

La linea
<A HREF=http://www.di.unito.it/concorsi/tecnici.html”>
N.2 CONTRATTI… </A>
IMG ALIGN=center SRC= “/icons/uni_logo2.gif” >
specifica un hypertext link.
http://www.di.unito.it/concorsi/tecnici.html
44
Accesso con autorizzazione

Spesso quando ci si collega ad un sito web
vengono richieste login e password.

Questo accesso si ottiene mediante speciali
header HTTP.
45
Accesso con autorizzazione
46
Accesso con autorizzazione
Dopo aver ricevuto il primo oggetto il client continua a mandare login e
password al server. Questi valori sono nella cache del browser e quindi
non viene richiesta ogni volta l’autenticazione.
47
Conditional GET

Il browser salva gli oggetti che visualizza nella sua
memoria cache.

Quando un utente richiede un oggetto che è già
nella cache, questo viene visualizzato in modo
immediato (es. pulsante Back).

Problema: cosa succede se la copia originale sul
server è stata modificata?
48
Conditional GET

Il client, ogni volta che memorizza un oggetto nella cache, tiene
traccia anche della data dell’ultima modifica.
Last-Modified: <data>

Ad ogni richiesta successiva il client può specificare la data della copia
in cache nella richiesta HTTP.
GET /dir/nomefile.gif HTTP/1.1
Host: www.somehost.it
If-modified-since: <data>
49
Conditional GET

Il server invia l’oggetto richiesto solo se è diverso da quello che
è già memorizzato nella cache del browser.

Altrimenti restituisce
HTTP/1.1 304 Not Modified
Date: Tue, 08 Apr 2003 08:38:48 GMT
Server: Apache/1.3.26 …
50
Conditional GET
51
Cookies

I Cookies consentono ai web server di memorizzare delle informazioni in un browser.
Questo meccanismo viene spesso usato per memorizzare variabili di sessione, user
preferences o user identity.

Sebbene i Cookies non facciano parte della specifica di HTTP essi diventano indispensabili
per ottenere un’interazione ottimale con alcuni siti web.

Quando un server vuole che il client memorizzi delle informazioni, il server invia uno
header Set-Cookie nella risposta al client. Questo header contiene il valore da
memorizzare.

Il client memorizza le informazioni contenute in Set-Cookie associate con la URL oppure il
dominio specificato.

In una richiesta successiva per tale URL il client deve includere le informazioni del cookie
usando lo header Cookie. Il server (o il programma CGI) usa queste informazioni per
inviare un documento adatto al client specifico.

Il server può includere expiration date per il cookie oppure utilizzarlo per una sola sessione
del browser.
52
Cookies (cont.)

Esempio di un client che richiede l’apertura di un account
POST /sales.ora.com/order.pl HTTP/1.0
[client headers…]
type=new&firstname=John&lastname=Smith

Il server memorizza queste informazioni associandole ad un nuovo account ID ed invia al client la risposta
HTTP/1.0 200 OK
[server headers…]
Set-Cookie: acct=04382374;domain=.ora.com;Expires=Sun, 16-Feb-2003 04:38:14 GMT; Path=/

La prossima volta che il browser visita il sito, il client dovrebbe riconoscere che è necessario un cookie ed
inviare
GET /order.pl HTTP/1.0
[client headers…]
Cookie: acct=04382374
53
Cookie: name=value

Permette di specificare coppie nome/valore per una certa URL.
• Cookie: acct=03847732

Cookie multipli possono essere specificati separandoli con ;.

I proxy server devono propagare header come Set-Cookie e
Cookie anche se la pagina è in cache (Set-Cookie non dovrebbe
essere mai memorizzato nella cache dei proxy).
54
Set-Cookie: name=value options

Contiene una coppia di informazioni nome/valore
associate alla URL. Serve ai browser per supportare
i cookie.
• Set-Cookie: acct=03845324
55