Corso di Laurea in Ingegneria delle Telecomunicazioni

Corso di Reti di Calcolatori

Alessio Botta ([Link]@[Link])

HTTP

I lucidi presentati al corso sono uno strumento didattico

che NON sostituisce i testi indicati nel programma del corso
 Nota di copyright per le slide COMICS

Nota di Copyright
Questo insieme di trasparenze è stato ideato e realizzato dai
ricercatori del Gruppo di Ricerca COMICS del Dipartimento di
Informatica e Sistemistica dell’Università di Napoli Federico II.
Esse possono essere impiegate liberamente per fini didattici
esclusivamente senza fini di lucro, a meno di un esplicito consenso
scritto degli Autori. Nell’uso dovranno essere esplicitamente riportati
la fonte e gli Autori. Gli Autori non sono responsabili per eventuali
imprecisioni contenute in tali trasparenze né per eventuali problemi,
danni o malfunzionamenti derivanti dal loro uso o applicazione.

Autori:
Simon Pietro Romano, Antonio Pescapè, Stefano Avallone,
Marcello Esposito, Roberto Canonico, Giorgio Ventre, Alessio Botta
Il protocollo HTTP/1.0

• Hyper-Text Transfer Protocol

• Si basa su TCP
• Il client apre un socket verso il porto TCP 80 del server
(se non diversamente specificato)
• Il server accetta la connessione
• Il client manda una richiesta per uno specifico oggetto identificato mediante una
URL
• Il server risponde e chiude la connessione
• Il protocollo HTTP è stateless: né il server né il client mantengono a livello
HTTP informazioni relative ai messaggi precedentemente scambiati

3
URL : Uniform Resource Locator

• Un URL HTTP ha la seguente sintassi (RFC 2396) :

[Link]
• Host identifica il server
• Può essere sia un nome simbolico che un indirizzo IP in notazione dotted decimal
• Port è opzionale; di default è 80
• Path identifica la risorsa sul server
• es: images/[Link]
• #fragment identifica un punto preciso all’interno di un oggetto
• es: #paragrafo1
• ?query è usato per passare informazioni dal client al server
• es: dati inseriti nei campi di una form

Es.: [Link]
HTTP: versioni
• Il protocollo è definito in documenti RFC
• Negli anni si sono avute tre versioni

• HTTP 0.9
• HTTP 1.0 (1996)
• RFC 1945
• HTTP 1.1 (1997 e 1999)
• RFC 2068
• RFC 2616
• HTTP 2.0 (pubblicato 2015, originato da SPDY di Google)
• RFC 7540

NOTA: un RFC (Request For Comment) è un documento pubblico sottoposto alla comunità Internet al fine di essere valutato.
Ciò che è un RFC rappresenta uno standard de facto nella comunità Internet. Tutti gli RFC possono essere reperiti al sito
dell’Internet Engineering Task Force ([Link]
HTTP per il trasferimento di pagine web

• Tipicamente, una pagina web è descritta da un file testuale in formato HTML

(Hypertext Markup Language)
• La pagina è identificata mediante un indirizzo, detto URL
• Un file HTML può contenere riferimenti ad altri oggetti che arricchiscono la
pagina con elementi grafici
• Es. sfondo, immagini, ecc.
• Ciascun oggetto è identificato dal proprio URL
• Questi oggetti possono trovarsi anche su server web diversi
• Una volta ricevuta la pagina HTML, il browser estrae i riferimenti agli altri oggetti
che devono essere prelevati e li richiede attraverso una serie di connessioni
HTTP

6
HTTP per il trasferimento di pagine web (2)

1
n s e#
o
Pagina HTML
r e sp 1
p
htt e s t#
u
t p req e #2
ht
s pons Server A
e 2
pr t#
htt u e s
tp req
ht
htt
p r
e sp
htt ons
e#
Client p r 3
e qu
e st
#3

Server B
Es: richiesta di una pagina contenente immagini
1: il client apre una connessione TCP sul
porto 80 verso l’indirizzo [Link]

2: il server è in ascolto sul porto 80 ed

accetta la connessione

3: il client invia un messaggio di richiesta

HTTP della home page

4: il server analizza la richiesta HTTP,

prepara la risposta HTTP e la invia al
client
5: il server chiude la connessione TCP

6: il client effettua il parsing del

documento (es. HTML) contenuto nel
messggio di risposta HTTP, ne fa il
rendering sullo schermo e rileva che
all’interno della pagina sono presenti 3
collegamenti ad immagini.
7: per ciascuna delle immagini vengono
ripetuti i passi da 1 a 5.

8
Connessioni persistenti e non persistenti
non persistente persistente

• HTTP/1.0 (RFC 1945) • HTTP/1.1 (RFC 2068, RFC 2116)

• Il server analizza una richiesta, la • Sulla stessa connessione il server
serve e chiude la connessione analizza tutte le richieste e le serve
• 2 Round Trip Time (RTT) per • Il client riceve la pagina iniziale e invia
subito tutte le altre richieste
ciascuna richiesta
• Si hanno meno RTT ed un solo slow-
• Ogni richiesta subisce lo slow- start
start TCP
• Esiste anche una versione con
parallelismo (with pipelining)

9
Round Trip Time e connessioni HTTP

10
La connessione HTTP

client server client server client server

open open open

close
open

close
close
open close

close

HTTP 1.0 HTTP 1.1 HTTP 1.1

con pipelining
Non persistente Persistente Persistente con
pipelining

11
La connessione HTTP (2/2)

12
Il protocollo HTTP

• HTTP è un protocollo testuale (fino alla versione 1.1)

• I messaggi sono costituiti da sequenze di byte
• Ogni byte identifica un carattere secondo la tabella ASCII
• Il payload dei messaggi può essere comunque anche in
formato binario (es. un’immagine GIF, un video, ecc.)

* Come si vedrà più avanti HTTP è utilizzato anche per altri scopi. 13
Il messaggio HTTP/1.0 request: un esempio

Un esempio di messaggio GET

GET /path/[Link] HTTP/1.0

User-agent: Mozilla/4.0
Accept: text/html, image/gif, image/jpeg
Accept-language: it
RIGA VUOTA

indica la fine del messaggio

14
Il messaggio HTTP/1.0 request

METHOD SP URL SP VERSION CR LF

request
line
HEADER FIELD NAME : VALUE CR LF

field
Header lines
HEADER FIELD NAME : VALUE CR LF

CR LF

PAYLOAD

15
Il messaggio HTTP/1.0 response
codice di stato

HTTP/1.0 200 OK
Date: Mon, 16 Dec 2002 14:00:22 GMT
Server: Apache/1.3.24 (Win32)
Last-Modified: Fri, 13 Dec 2002 08:06:44 GMT
Content-Length: 222
Content-Type: text/html
RIGA VUOTA

PAYLOAD

16
Esempi di codici di stato
200 OK
•Successo: l’oggetto richiesto si trova più avanti nel messaggio

301 Moved Permanently

•L’oggetto richiesto è stato spostato.
Il nuovo indirizzo è specificato più avanti nel messaggio
( Location: )

400 Bad Request

•Richiesta incomprensibile al server

404 Not Found

•Il documento non è presente sul server

505 HTTP Version Not Supported

•La versione del protocollo HTTP usata non è supportata
dal server

17
Lo scambio di messaggi

• Il metodo GET
• Il metodo HEAD
• Il metodo POST
• Il metodo PUT

• La response

18
Il metodo GET
• Uno dei più importanti metodi di HTTP è GET
• Usato per richiedere una risorsa ad un server
• Questo è il metodo più frequente, ed è quello che viene attivato facendo click su un
link ipertestuale di un documento HTML, o specificando un URL nell’apposito campo
di un browser
• GET può essere:
• assoluto
• la risorsa viene richiesta senza altre specificazioni
• condizionale
• si richiede la risorsa se è soddisfatto un criterio indicato negli header
If-match, If-modified-since, If-range, ecc.
• parziale
• si richiede una sottoparte di una risorsa memorizzata

19
Il metodo GET: un esempio

20
Il metodo HEAD

• Simile al metodo GET, ma il server deve rispondere soltanto con gli header relativi,
senza il corpo
• Usato per verificare:
• la validità di un URI
• la risorsa esiste e non è di lunghezza zero
• l’accessibilità di un URI
• la risorsa è accessibile presso il server, e non sono richieste procedure di autenticazione del
documento
• la coerenza di cache di un URI
• la risorsa non è stata modificata nel frattempo, non ha cambiato lunghezza, valore hash o data di
modifica

21
Il metodo POST
• Il metodo POST serve per trasmettere delle informazioni dal client al server, ma
senza la creazione di una nuova risorsa
• POST viene usato per esempio per sottomettere i dati di una form HTML ad
un’applicazione sul server
• I dati vengono trasmessi nel body della richiesta
• Il server può rispondere positivamente in tre modi:
• 200 Ok: dati ricevuti e sottomessi alla risorsa specificata; è stata data risposta
• 201 Created: dati ricevuti, la risorsa non esisteva ed è stata creata
• 204 No content: dati ricevuti e sottomessi alla risorsa specificata; non è stata data risposta
• Non è l’unico modo per inviare dati

22
Il metodo POST: un esempio

23
Il metodo PUT
• Il metodo PUT serve per trasmettere delle informazioni dal client al server, creando o
sostituendo la risorsa specificata
• Esempio: upload di un file
• In generale, l’argomento del metodo PUT è la risorsa che ci si aspetta di ottenere
facendo un GET in seguito con lo stesso nome

24
HTTP: Response
• La risposta HTTP è un messaggio testuale formato da una riga iniziale,
da header facoltativi ed eventualmente un body (corpo)
Version status-code reason-phrase CRLF request
line
[Header]
[Header]
Header
CRLF
Body
dove:
[Header] indica un elemento opzionale
CRLF indica la sequenza di caratteri di codice ASCII
0D16 = 1310 ® CR = Carriage Return
0A16 = 1010 ® LF = Line Feed

25
HTTP: Response (2)
• Un Esempio:

HTTP/1.1 200 OK
Date: Thu, 10 Apr 2003 11:46:53 GMT
Server: Apache/1.3.26 (Unix) PHP/4.0.3pl1
Last-Modified: Wed, 18 Dec 2002 12:55:37 GMT
Accept-Ranges: bytes
Content-Length: 7394
Content-Type: text/html

<HTML> … </HTML>

26
HTTP Response: un esempio

27
Status code
• Lo status code è un numero di tre cifre, di cui la prima indica la classe della risposta,
e le altre due la risposta specifica
• Esistono le seguenti classi:
• 1xx: Informational
• Una risposta temporanea alla richiesta, durante il suo svolgimento
• 2xx: Successful
• Il server ha ricevuto, capito e accettato la richiesta
• 3xx: Redirection
• Il server ha ricevuto e capito la richiesta, ma sono necessarie altre azioni da parte del client per portare a
termine la richiesta
• 4xx: Client error
• La richiesta del client non può essere soddisfatta per un errore da parte del client (errore sintattico o
richiesta non autorizzata)
• 5xx: Server error
• La richiesta può anche essere corretta, ma il server non è in grado di soddisfare la richiesta per un
problema interno

28
Status code: alcuni esempi
• 100 Continue
• se il client non ha ancora mandato il body
• 200 Ok
• GET con successo
• 201 Created
• PUT con successo
• 301 Moved permanently
• URL non valida, il server conosce la nuova posizione
• 400 Bad request
• errore sintattico nella richiesta
• 401 Unauthorized
• manca l’autorizzazione
• 403 Forbidden
• richiesta non autorizzabile
• 404 Not found
• URL errato
• 500 Internal server error
• tipicamente un programma in esecuzione sul server ha generato errore
• 501 Not implemented
• metodo non conosciuto dal server

29
Gli header di risposta

• Gli header della risposta sono posti dal server per specificare
informazioni sulla risposta e su se stesso al client

• Server: una stringa che descrive il server: tipo, sistema operativo e

versione
• Accept-ranges: specifica che tipo di range può accettare (valori
previsti: byte e none)

30
Gli header generali
• Gli header generali si applicano solo al messaggio trasmesso e si applicano sia ad
una richiesta che ad una risposta, ma non necessariamente alla risorsa trasmessa
• Date: data ed ora della trasmissione
• MIME-Version: la versione MIME usata per la trasmissione (sempre 1.0)
• Transfer-Encoding: il tipo di formato di codifica usato per la trasmissione
• Cache-Control: il tipo di meccanismo di caching richiesto o suggerito per la risorsa
• Connection: il tipo di connessione da usare
• Connection: Keep-Alive ® tenere attiva dopo la risposta
• Connection: Close ® chiudere dopo la risposta
• Via: usato da proxy e gateway

* MIME, Multipurpose Internet Mail Extensions - RFC 2045-2056 31

Gli header dell’entità
• Gli header dell’entità danno informazioni sul body del messaggio, o, se non vi è body, sulla risorsa
specificata
• Content-Type: oggetto/formato
• Ogni coppia oggetto/formato costituisce un tipo MIME dell’entità acclusa
• Specifica se è un testo, se un’immagine GIF, un’immagine JPG, un suono WAV, un filmato MPG, ecc…
• Obbligatorio in ogni messaggio che abbia un body
• Content-Length: la lunghezza in byte del body
• Obbligatorio, soprattutto se la connessione è persistente
• Content-Base, Content-Encoding, Content-Language,
Content-Location, Content-MD5, Content-Range: l’URL di base, la codifica, il linguaggio, l’URL
della risorsa specifica, il valore di digest MD5 e il range richiesto della risorsa
• Expires: una data dopo la quale la risorsa è considerata non più valida
(e quindi va richiesta o cancellata dalla cache)
• Last-Modified: la data e l’ora dell’ultima modifica
• Serve per decidere se la copia posseduta (es. in cache) è ancora valida o no
• Obbligatorio se possibile

32
Una prova con telnet
> telnet [Link] 80
GET / HTTP/1.0 Requ
est-lin
e
HTTP/1.1 200 OK
Date: Mon, 25 Oct 2010 23:02:38 GMT
Server: Apache/2.2.14 (Unix) mod_jk/1.2.28 DAV/2
ETag: W/"2097-1213082454000"
Last-Modified: Tue, 10 Jun 2008 07:20:54 GMT
Content-Length: 2097
Connection: close
o n se
Content-Type: text/html p
Res

33
I cookies

• HTTP è stateless: il server non è tenuto a mantenere informazioni su

connessioni precedenti
• Un cookie è una breve informazione scambiata tra il server ed il client
• Tramite un cookie il client mantiene lo stato di precedenti connessioni, e
lo manda al server di pertinenza ogni volta che richiede un documento
• Esempio: tramite un cookie viene riproposta la propria username all’atto
dell’accesso ad un sito per la posta
• I cookies sono definiti in RFC2109(su proposta di Netscape)

34
Cookies: header specifici
• Il meccanismo dei cookies dunque definisce due nuovi possibili header: uno per la
risposta, ed uno per le richieste successive
• Set-Cookie: header della risposta
• il client può memorizzarlo (se vuole) e rispedirlo alla prossima richiesta
• Cookie: header della richiesta
• il client decide se spedirlo sulla base del nome del documento, dell’indirizzo IP del server, e dell’età del
cookie
• Un browser può essere configurato per accettare o rifiutare i cookies
• Alcuni siti web richiedono necessariamente la capacità del browser di accettare i
cookies

35
Non solo browsing…

• HTTP non è utilizzato solo per il Web

• Ad esempio:
• XML e VoiceXML trasportati su HTTP
• Web Services e SOA (Service Oriented Architecture)
• Video streaming
• Peer-to-peer

36
Adozione in corso: HTTP2

• HTTP2 ha diverse caratteristiche che lo differenziano da HTTP1.1

• protocollo binario
• compressione degli header
• Server push
• Multiplexing
• La fase iniziale della connessione è molto simile ad HTTP 1.x, poi:
• ‘Upgrade’ header
• ALPN negotiation for TLS (httpS)
• Oppure direttamente ‘PRI’ request method
(se è noto che server supporta HTTP2)

37