Una tipica sessione HTTP
Nei protocolli client-server, come HTTP, le sessioni sono composte da tre fasi:
Il client stabilisce una connessione TCP (o la connessione appropriata se il livello di trasporto non è TCP).
Il client invia la sua richiesta e attende la risposta.
Il server elabora la richiesta, inviando la sua risposta, fornendo un codice di stato e dati appropriati.
A partire da HTTP/1.1, la connessione non viene più chiusa dopo aver completato la terza fase e al client viene ora concessa un’ulteriore richiesta: ciò significa che la seconda e la terza fase possono ora essere eseguite un numero qualsiasi di volte.
Stabilire una connessione
Nei protocolli client-server, è il client che stabilisce la connessione. Aprire una connessione in HTTP significa avviare una connessione nel livello di trasporto sottostante, solitamente TCP.
Con TCP la porta predefinita, per un server HTTP su un computer, è la porta 80. Possono essere utilizzate anche altre porte, come 8000 o 8080. L’URL di una pagina da recuperare contiene sia il nome di dominio, sia il numero di porta, sebbene quest’ultimo possa essere omesso se è 80. Vedere il riferimento URL per maggiori dettagli
Invio di una richiesta client
Una volta stabilita la connessione, l’agente utente può inviare la richiesta (un agente utente è in genere un browser Web, ma può essere qualsiasi altra cosa, ad esempio un crawler). Una richiesta client è composta da direttive di testo, separate da CRLF (ritorno a capo, seguito da avanzamento riga), divise in tre blocchi:
La prima riga contiene un metodo di richiesta seguito dai suoi parametri:
il percorso del documento, come URL assoluto senza protocollo o nome di dominio
la versione del protocollo HTTP
Le righe successive rappresentano un’intestazione HTTP, che fornisce al server informazioni sul tipo di dati appropriato (ad esempio, quale lingua, quali tipi MIME) o altri dati che ne alterano il comportamento (ad esempio, non inviare una risposta se è già memorizzata nella cache). Queste intestazioni HTTP formano un blocco che termina con una riga vuota.
Il blocco finale è un blocco dati facoltativo, che può contenere ulteriori dati utilizzati principalmente dal metodo POST.
Richieste di esempio
Recupero della pagina principale di wp-hosting.it/, (https://www.wp-hosting.it/), e comunicazione al server che l’agente utente preferirebbe la pagina in inglese, se possibile:
HTTP GET / HTTP/1.1 Host: wp-hosting.it Accept-Language: en
Osserva la riga vuota finale, che separa il blocco dati dal blocco header. Poiché non è fornito alcun Content-Length in un header HTTP, questo blocco dati viene presentato vuoto, segnando la fine degli header, consentendo al server di elaborare la richiesta nel momento in cui riceve questa riga vuota.
Ad esempio, inviando il risultato di un modulo:
http Copy to Clipboard POST /form-contatti.php HTTP/1.1 Host: wp-hosting.it Content-Length: 64 Content-Type: application/x-www-form-urlencoded name=Mario%20User&request=Send%20me%20one%20of%20your%20catalogue
Metodi di richiesta
HTTP definisce un set di metodi di richiesta che indicano l’azione desiderata da eseguire su una risorsa. Sebbene possano anche essere nomi, questi metodi di richiesta sono talvolta indicati come verbi HTTP. Le richieste più comuni sono GET e POST:
Il metodo GET richiede una rappresentazione dei dati della risorsa specificata. Le richieste che utilizzano GET devono solo recuperare i dati.
Il metodo POST invia i dati a un server in modo che possa cambiare il suo stato. Questo è il metodo spesso utilizzato per i moduli HTML.
Struttura di una risposta del server
Dopo che l’agente connesso ha inviato la sua richiesta, il server Web la elabora e alla fine restituisce una risposta. Simile a una richiesta client, una risposta del server è formata da direttive di testo, separate da CRLF, sebbene divise in tre blocchi:
- La prima riga, la riga di stato, è costituita da un riconoscimento della versione HTTP utilizzata, seguita da un codice di stato della risposta (e dal suo breve significato in testo leggibile dall’uomo).
- Le righe successive rappresentano specifiche intestazioni HTTP, che forniscono al client informazioni sui dati inviati (ad esempio, tipo, dimensione dei dati, algoritmo di compressione utilizzato, suggerimenti sulla memorizzazione nella cache). Similmente al blocco di intestazioni HTTP per una richiesta client, queste intestazioni HTTP formano un blocco che termina con una riga vuota.
- Il blocco finale è un blocco dati, che contiene i dati facoltativi.
Risposte di esempio
Risposta di pagina Web riuscita:
HTTP HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Length: 55743 Connection: keep-alive Cache-Control: s-maxage=300, public, max-age=0 Content-Language: it Date: Thu, 06 Dec 2018 17:37:18 GMT ETag: "2e77ad1dc6ba0a53a2996dfd4653c1c3" Server: meinheld/0.6.1 Strict-Transport-Security: max-age=63099000 X-Content-Type-Options: nosniff X-Frame-Options: DENY X-XSS-Protection: 1; mode=block Vary: Accept-Encoding,Cookie Age: 7
Notifica che la risorsa richiesta è stata spostata definitivamente:
HTTP/1.1 301 Moved Permanently Server: Apache/2.4.37 (Red Hat) Content-Type: text/html; charset=utf-8 Date: Thu, 06 Dec 2018 17:33:08 GMT Location: https://wp-hosting.it/ (questo è il nuovo collegamento alla risorsa; ci si aspetta che l'agente utente lo recuperi) Keep-Alive: timeout=15, max=98 Accept-Ranges: bytes Via: WPH-Cache-zlb05 Connection: Keep-Alive Content-Length: 325 (il contenuto contiene una pagina predefinita da visualizzare se l'agente utente non è in grado di seguire il collegamento) … (contiene una pagina personalizzata del sito che aiuta l'utente a trovare la risorsa mancante)
Notifica che la risorsa richiesta non esiste:
HTTP/1.1 404 Not Found Content-Type: text/html; charset=utf-8 Content-Length: 38217 Connection: keep-alive Cache-Control: no-cache, no-store, must-revalidate, max-age=0 Content-Language: it Date: Thu, 06 Dec 2018 17:35:13 GMT Expires: Thu, 06 Dec 2018 17:35:13 GMT Server: meinheld/0.6.1 Strict-Transport-Security: max-age=63099000 X-Content-Type-Options: nosniff X-Frame-Options: DENY X-XSS-Protection: 1; mode=block Vary: Accept-Encoding,Cookie X-Cache: Error from cloudfront … (contiene una pagina personalizzata del sito che aiuta l'utente a trovare la risorsa mancante)
Codici di stato della risposta
I codici di stato della risposta HTTP indicano se una specifica richiesta HTTP è stata completata correttamente. Le risposte sono raggruppate in cinque classi: risposte informative, risposte riuscite, reindirizzamenti, errori del client ed errori del server.
- 200: OK. La richiesta è riuscita.
- 301: Spostato in modo permanente. Questo codice di risposta indica che l’URI della risorsa richiesta è stato modificato.
- 404: Non trovato. Il server non riesce a trovare la risorsa richiesta.