Nei protocolli client-server come l’HTTP, la sessione è composta da tre fasi:
- Il cliente stabilisce una connessione TCP (o l’appropriata connessione nel caso non sia TCP).
- Il cliente manda la sua richiesta e aspetta per la risposta.
- Il server processa la richiesta, mandando poi la sua risposta, con al suo interno il codice di stato e un dato appropriato.
Da quando è uscito HTTP/1.1, la connessione non si chiude più dopo la terza fase, e il cliente può fare un altra richiesta: questo significa che la seconda e terza fase possono essere usate molte 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, che di solito è il TCP.
Con TCP la porta di default, per un server HTTP su un computer, è la porta 80. Possono essere usate anche altre porte, come la 8000 o la 8080. L’URL della pagina da raggiungere contiene sia il nome del dominio che la numero di porta, anche se quest’ultimo può essere omesso se è 80. Vedi identificare le risorse sul web per maggiori dettagli.
Mandare una client request
Una volta che la connessione si è stabilita, il programma utente può mandare la richiesta (un programma utente è tipicamente un web browser, ma può essere tante cose, per esempio un motore di ricerca). Una client request consiste nelle direttive testuali, separate dal CRLF (carriage return line feed), divise in 3 blocchi:
- La prima riga contiene un request method seguito dai suoi parametri:
- il percorso di un documento, quindi l’URL assoluto senza protocollo o dominio.
- Versione del protocollo HTTP.
- righe susseguenti rappresentano un header HTTP, che danno al server le informazioni su quale tipo di dato è più appropriato (ad esempio che liguaggio o tipo di MIME) o altri dati che alterano il suo comportamento (ad esempio non mandare una risposta anche se già memorizzata nella cache). Gli header HTTP formano un blocco che termina con una riga vuota.
- L’ultimo blocco è facoltativo, e contiene dati superflui usati principalmente dal POST method.
Esempi:
recuperare la pagina radice di developer.mozilla.org , e dire al server che il programma utente preferirebbe, se possibile, avere la pagina in lingua francese.
GET / HTTP/1.1 Host: developer.mozilla.org Accept-Language: fr
Si osservi che l’ultima riga è vuota, questo separa il blocco data da quello header. Dato che non c’è nessuna content-lenght nell’ header HTTP, questo blocco di dati si presenta vuoto, marcando la fine degli headers, permettendo così al server di processare la richiesta dal momento in cui riceve quella riga vuota.
Per esempio, mandando il risultato di un form:
POST /contact_form.php HTTP/1.1 Host: developer.mozilla.org Content-Length: 64 Content-Type: application/x-www-form-urlencoded name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
Metodi di richiesta
L’HTTP definisce un set di richieste metodo che indicano l’azione desiderata da fare a seconda della risorsa. Anche se possono essere nomi, queste richieste sono alcune volte riferite come dei verbi HTTP. La richieste più comuni sono GET e POST:
- il metodo GET richiede un dato rappresentante la risorsa specificata. Richieste fatte usando il GET può solo recuperare dati.
- Il metodo POST invia dati al server che potrebbe cambiare il suo stato. Questo è il metodo spesso usati per i Form HTML.
Struttura di una risposta server
Dopo che l’agente connesso ha inviato la richiesta, il web server lo processa, e alla fine restituisce una risposta. Analogamente alla richiesta client, una risposta server è formata da direttive, separate dal CRLF, sebbene divise in tre blocchi:
- La prima linea, lastatus line, consiste in un riconoscimento della versione http usata, seguita da un status request (e il suo breve significato in parole comprensibili dall’uomo).
- Le righe successive rappresentano specifici header HTTP, che danno al client informazioni riguardanti i dati inviati (per esempio: tipo, dimensione dei dati, algoritmo di compressione usato, note sul caching). Analogamente al blocco di header HTTP di una richiesta client, questi header HTTP formano un blocco finale con una linea vuota.
- Il blocco finale è un blocco di dati, che contieni i dati opzionali.
Esempio di risposte
Risposta pagina web riuscita:
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: en-US Date: Thu, 06 Dec 2018 17:37:18 GMT ETag: "2e77ad1dc6ab0b53a2996dfd4653c1c3" Server: meinheld/0.6.1 Strict-Transport-Security: max-age=63072000 X-Content-Type-Options: nosniff X-Frame-Options: DENY X-XSS-Protection: 1; mode=block Vary: Accept-Encoding,Cookie Age: 7 <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>A simple webpage</title> </head> <body> <h1>Simple HTML5 webpage</h1> <p>Hello, world!</p> </body> </html>
Notifica che la risorsa richiesta è stata definitivamente trasferita:
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://developer.mozilla.org/ (questo è il nuovo link della risorsa; ci si aspetta che l’utente agente lo prenda) Keep-Alive: timeout=15, max=98 Accept-Ranges: bytes Via: Moz-Cache-zlb05 Connection: Keep-Alive Content-Length: 325 (Il contenuto è una pagina di default da mostrare se l’utente agente non è in grado di seguire il link) <!DOCTYPE html... (contiene un pagina personalizzata 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: en-US 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=63072000 X-Content-Type-Options: nosniff X-Frame-Options: DENY X-XSS-Protection: 1; mode=block Vary: Accept-Encoding,Cookie X-Cache: Error from cloudfront <!DOCTYPE html... (contiene un pagina personalizzata che aiuta l’utente a trovare la risorsa mancante)
Status code di risposta
HTTP response status codes indica se una specifica richiesta HTTP sia stata completata con successo. Le risposte sono suddivise in cinque classi: risposte informative, risposte di successo, reindirizzamenti, errori client, ed errori server.