HTTP
HTTP sta per Hyper Text Transfer Protocol ed è un protocollo di trasferimento di ipertesti del livello superiore della suite Internet.
E’ stato inventato nel 1989 da Tim Berners-Lee insieme a tutto ciò che compone il World Wide Web: il protocollo HTTP, il linguaggio HTML, il primo browser WorldWideWeb e il primo server web, httpd.
Note
Commento del prof
HTTP è una invenzione rivoluzionaria nel mondo di oggi, paragonabile a quella della scrittura. E’ la tecnologia che ha spinto Internet a diventare quello che è oggi.
Ha cambiato il mondo più dell’auto, ha diffuso idee, comportamenti e indicato acquisti più della carta.
E’ il motivo per cui oggi tutti abbiamo un telefono in tasca.
HTTP si sviluppa a partire dal 1989 ad oggi secondo varie innovazioni e cambiamenti. Vediamo prima una tabella riassuntiva delle cose che più di tutti hanno modificato il protocollo. Poi vedremo quelle che sono le sue caratteristiche principali.
Riepilogo delle principali versioni HTTP
| Versione | Anno | RFC |
|---|---|---|
| HTTP/0.9 | 1991 | RFC ???? |
| HTTP/1.1 | 1999 | RFC 2616 |
| HTTP/2 | 2015 | RFC 7540 |
| HTTP/3 | 2022 | RFC 9114 |
HTTP 0
HTTP 0.9 è l’ultima delle versioni originali del protocollo. Permette il trasferimento solo di testo semplice, quindi di file HTML statici senza immagini.
HTTP 1
HTTP 1 è la versione che fa la differenza per HTTP: permette l’invio di dati in formato binario, oltre al testo, grazie alla tecnica (importata dai protocolli di mail)
dei MIME types da inserire nel nuovo header della risposta, il Content-Type.
HTTP 1.1 in particolare è importante perché rende obbligatorio l’uso dell’header Host nella richiesta. Questo permette ad un unico server di servire più siti web, identificati tramite il nome del dominio lì presente: questa novità introduce una nuova tipologia di azienda: le web farm and hosting companies.
HTTP 2
Il difetto principale di HTTP 1 era la lentezza: le risposte erano inviate in modo sequenziale, una dopo l’altra, senza possibilità di inviare più dati contemporaneamente. L’obiettivo principale per HTTP 2 è la velocità!
HTTP 2 introduce il multiplexing, ovvero la possibilità di inviare più richieste contemporaneamente su un’unica connessione e introduce la compressione obbligatoria degli header, così da ridurre la dimensione totale da inviare. Si apre dunque una unica connessione per tutte le richieste, che viaggiano in multiplexing; al termine, la connessione viene chiusa.
HTTP 3
HTTP 3 si occupa invece del problema della sicurezza: introduce la crittografia in HTTP in maniera obbligatoria, non opzionale come su HTTP 1 e HTTP 2.
Inoltre si preoccupa di risolvere il problema del carico aggiuntivo di lavoro che questa sicurezza comporta: viene introdotto il protocollo QUIC, che si basa su UDP, come protocollo di trasporto più efficiente con la crittografia di TLS 1.3 integrata.
Caratteristiche principali
Le caratteristiche che vado ad elencare sono quelle comuni a tutte le versioni di HTTP!
Il protocollo HTTP è un protocollo basato sulla tipologia client/server e sul meccanismo, comunissimo nelle comunicazioni di rete di alto livello, di request/reply (richiesta/risposta): il client esegue una richiesta ed il server restituisce la risposta e poi la connessione viene chiusa (protocollo stateless, senza stato, cioè che non mantiene la connessione attiva).
Il protocollo HTTP si appoggia a livello di trasporto sul protocollo TCP e utilizza lato server la porta 80, mentre la versione HTTPS utilizza la porta 443. La versione 3 del protocollo HTTP si basa su QUIC e utilizza la porta 443 avendo crittografia integrata.
Richiesta e risposta sono comunissimi file di testo: questo serve HTTP facile da implementare, gestire, studiare e “controllare”. Ogni coppia request/reply corrisponde ad un unico file da scambiare fra client e server: questo significa che se un sito è costituito da una pagina con 20 immagini saranno necessarie 20+1 risposte per inviarle tutte! Nel caso di HTTP 1 vi erano 21 coppie richiesta/risposta. Da HTTP 2 in avanti, nel caso di un sito ben configurato sul server, è sufficiente una sola richiesta per ottenere tutte le risorse necessarie.
Richieste HTTP
Il messaggio di richiesta HTTP è composto di tre parti:
- Riga di richiesta (request line)
- Sezione Header (informazioni aggiuntive)
- Body (corpo del messaggio)
La riga di richiesta è composta a sua volta da tre informazioni:
- la versione del protocollo: es:
HTTP/1.1. - il metodo di richiesta; obbligatorio conoscere almeno i metodi GET, POST, HEAD, PUT.
- L’
URL; l’informazione che identifica l’oggetto della richiesta (ad esempio la pagina del sito che si vuole vedere).
I metodi HTTP indicano le cose che il protocollo può fare e identificano dunque le azioni da eseguire.
Il metodo GET è il più utilizzato e serve a richiedere una pagina specifica. Si attende la risorsa corrispondente all’URL specificato pensando che
arrivi nel body della risposta associata alla richiesta.
Il metodo HEAD è identifico al metodo GET, se non per una importante differenza: il body della risposta associata ad una richiesta HEAD è sempre vuoto! Questo tipo di richiesta è utilizzato per ottenere solo l’header della risposta, senza il body.
Il metodo POST è utilizzato per inviare dati dal client al server; i dati saranno inseriti nel body della richiesta . La risposta associata a una richiesta POST può contenere una conferma di ricezione, una pagina di accesso (nel caso ad esempio che i dati inviati siano delle credenziali di accesso), o un errore.
Il metodo PUT è utilizzato per l’upload di file dal cliente al server. Anche qui, il file da caricare andrà nel body della richiesta e la risposta sarà una semplice conferma di ricezione.
Gli header di richiesta più comuni sono:
- Host: Nome del server a cui si riferisce l’URI. È obbligatorio nelle richieste conformi HTTP/1.1 perché permette l’uso dei virtual host basati sui nomi.
- User-Agent: Identificazione del tipo di client: tipo browser, produttore, versione…
- Referer: indica l’URL che ha “prodotto” la richiesta corrente.
- Accept-Language: lista delle lingue che l’utente è in grado di comprendere
Il body contiene il corpo del messaggio. Il suo contenuto dipende dal metodo utilizzato:
- è vuoto con i metodi GET e HEAD.
- contiene i dati da inviare con il metodo POST
- il file di cui fare l’upload con il metodo PUT
- etc…
HTTP/1.1 GET /
Host: www.adjam.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 ...
Accept-Language: it
... (body) ...
Risposte HTTP
Il messaggio di risposta è anch’esso composto da tre parti:
- Riga di stato (status-line)
- Sezione header
- Body (contenuto della risposta)
La riga di stato riporta (anche qui) tre informazioni:
- la versione HTTP (es.
HTTP/1.1) - un codice numerico a tre cifre che identifica il tipo di risposta. I numeri vanno da 100 a 599. Le centinaia identificano il tipo di risposta
- una descrizione testuale della risposta (es.
OK,Not Found,Internal Server Error)
Vediamo le diverse tipologie:
- 1xx: Informational (messaggi informativi, non di errore)
- 2xx: Success (la richiesta è stata soddisfatta)
- 3xx: Redirection (la risorsa non è presente, ma si hanno informazioni su come raggiungerla)
- 4xx: Client error (la richiesta non può essere soddisfatta perché sbagliata)
- 5xx: Server error (la richiesta non può essere soddisfatta per un problema interno del server)
Note
Ovviamente non tutti i 500 numeri sono utilizzati nella realtà!
Wikipedia riporta un elenco aggiornato delle status line esistenti (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes).
Gli header della risposta più comuni sono:
- Server: Indica tipo e versione del server
- Content-Type: Indica il tipo di contenuto restituito (tipo MIME).
- Content-encoding: Indica se il contenuto è stato compresso oppure no.
- Content-length: Indica la lunghezza in byte del body
Il body della risposta è tipicamente il posto dove troviamo le informazioni trasportate: ad esempio, in caso di una richiesta GET, il body della risposta contiene il file da trasportare al client.
HTTP/1.1 200 OK
Server: Apache
Content-Encoding: gzip
Content-Length: 1122
Content-Type: text/html
... (seguita dal body coi dati richiesti) ...