5-RdC HTTP
5-RdC HTTP
HTTP
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
3
URL : Uniform Resource Locator
Es.: http://www.unina.it/immatricolazioni.htm#ingegneria
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 (http://www.ietf.org)
HTTP per il trasferimento di pagine web
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 www.unina.it
8
Connessioni persistenti e non persistenti
non persistente persistente
9
Round Trip Time e connessioni HTTP
10
La connessione HTTP
close
open
close
close
open close
close
11
La connessione HTTP (2/2)
12
Il protocollo HTTP
* Come si vedrà più avanti HTTP è utilizzato anche per altri scopi. 13
Il messaggio HTTP/1.0 request: un esempio
14
Il messaggio HTTP/1.0 request
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
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
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
32
Una prova con telnet
> telnet www.unina.it 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
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…
36
Adozione in corso: HTTP2
37