Una tipica sessione HTTP

Nei protocolli client-server come l’HTTP, la sessione è composta da tre fasi:

1. Il cliente stabilisce una connessione TCP (o l’appropriata connessione nel caso non sia TCP).
2. Il cliente manda la sua richiesta e aspetta per la risposta.
3. 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.

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.

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:

1. 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.
2. 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.
3. L’ultimo blocco è facoltativo, e contiene dati superflui usati principalmente dal POST method.

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

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.

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:

1. 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).
2. 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.
3. Il blocco finale è un blocco di dati, che contieni i dati opzionali.

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)

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.

• 200: OK. La richiesta ha avuto successo.
• 301: Definitivamente Trasferita. Questo codice di risposta significa che l’URL della risorsa richiesta è stata cambiata.
• 404: Non trovato. Il server non riesce a trovare la risorsa richiesta.

• Identificare le risorse sul web
• Header HTTP
• Metodi di risposta HTTP
• Status codes di risposta HTTP