HTTP

Cos’è HTTP?

HyperText Transfer Protocol (HTTP) è il protocollo di rete che consente il trasferimento di documenti ipermediali sul Web, in genere tra un browser e un server in modo che gli esseri umani possano leggerli. La versione attuale della specifica HTTP è chiamata HTTP/2.

Come parte di un URI, “http” all’interno di “http://esempio.com/” è chiamato “schema”. Le risorse che utilizzano lo schema “http” vengono in genere trasportate tramite connessioni non crittografate tramite il protocollo HTTP.

Lo schema “https” (come in “https://wp-hosting.it”) indica che una risorsa viene trasportata tramite il protocollo HTTP, attraverso un canale TLS sicuro.

HTTP è testuale (tutte le comunicazioni vengono eseguite in testo normale) e senza stato (nessuna comunicazione è a conoscenza delle comunicazioni precedenti). Questa proprietà lo rende ideale agli esseri umani per leggere documenti (siti Web) sul World Wide Web.

Tuttavia, HTTP può anche essere utilizzato come base per servizi Web REST da server a server o richieste fetch() all’interno di siti Web per renderli più dinamici.

Panoramica di HTTP

HTTP è un protocollo per il recupero di risorse come documenti HTML. È il fondamento di qualsiasi scambio di dati sul Web ed è un protocollo client-server, il che significa che le richieste vengono avviate dal destinatario, solitamente il browser Web. Un documento completo è in genere costituito da risorse come contenuto di testo, istruzioni di layout, immagini, video, script e altro.

Client e server comunicano scambiandosi singoli messaggi (in contrapposizione a un flusso di dati). I messaggi inviati dal client sono chiamati richieste e i messaggi inviati dal server come risposta sono chiamati risposte.

Progettato nei primi anni ’90, HTTP è un protocollo estensibile che si è evoluto nel tempo.

È un protocollo di livello applicativo inviato tramite TCP o tramite una connessione TCP crittografata TLS, sebbene teoricamente potrebbe essere utilizzato qualsiasi protocollo di trasporto affidabile. Grazie alla sua estensibilità, viene utilizzato non solo per recuperare documenti ipertestuali, ma anche immagini e video o per pubblicare contenuti sui server, come con i risultati dei moduli HTML. HTTP può anche essere utilizzato per recuperare parti di documenti per aggiornare le pagine Web su richiesta.

Componenti dei sistemi basati su HTTP

HTTP è un protocollo client-server: le richieste vengono inviate da un’entità, l’user-agent (o un proxy per conto di esso). Nella maggior parte dei casi l’user-agent è un browser Web, ma può essere qualsiasi cosa, ad esempio un robot che esplora il Web per popolare e gestire un indice del motore di ricerca.

Ogni singola richiesta viene inviata a un server, che la gestisce e fornisce una risposta chiamata response. Tra il client e il server ci sono numerose entità, collettivamente chiamate proxy, che eseguono diverse operazioni e fungono da gateway o cache, ad esempio.

In realtà, ci sono più computer tra un browser e il server che gestisce la richiesta: ci sono router, modem e altro. Grazie alla progettazione a strati del Web, questi sono nascosti nei livelli di rete e di trasporto. HTTP è in cima, a livello di applicazione. Sebbene importante per la diagnosi dei problemi di rete, i livelli sottostanti sono per lo più irrilevanti per la descrizione di HTTP.

Client: l’user-agent

L’user-agent è qualsiasi strumento che agisce per conto dell’utente. Questo ruolo è svolto principalmente dal browser Web, ma può essere svolto anche da programmi utilizzati da ingegneri e sviluppatori Web per il debug delle loro applicazioni.

Il browser è sempre l’entità che avvia la richiesta. Non è mai il server (sebbene nel corso degli anni siano stati aggiunti alcuni meccanismi per simulare messaggi avviati dal server).

Per visualizzare una pagina Web, il browser invia una richiesta originale per recuperare il documento HTML che rappresenta la pagina. Quindi analizza questo file, effettuando richieste aggiuntive corrispondenti a script di esecuzione, informazioni di layout (CSS) da visualizzare e sotto-risorse contenute nella pagina (solitamente immagini e video). Il browser Web quindi combina queste risorse per presentare il documento completo, la pagina Web. Gli script eseguiti dal browser possono recuperare più risorse in fasi successive e il browser aggiorna la pagina Web di conseguenza.

Una pagina Web è un documento ipertestuale. Ciò significa che alcune parti del contenuto visualizzato sono collegamenti, che possono essere attivati (solitamente con un clic del mouse) per recuperare una nuova pagina Web, consentendo all’utente di indirizzare il proprio user-agent e navigare nel Web. Il browser traduce queste istruzioni in richieste HTTP e interpreta ulteriormente le risposte HTTP per presentare all’utente una risposta chiara.

Il server Web

Dall’altro lato del canale di comunicazione c’è il server, che serve il documento come richiesto dal client. Un server appare come una sola macchina virtuale; ma in realtà può essere una raccolta di server che condividono il carico (bilanciamento del carico) o altri software (come cache, un server di database o server di e-commerce), che generano totalmente o parzialmente il documento su richiesta.

Un server non è necessariamente una singola macchina, ma diverse istanze di software server possono essere ospitate sulla stessa macchina. Con HTTP/1.1 e l’intestazione Host, possono persino condividere lo stesso indirizzo IP.

Proxy

Tra il browser Web e il server, numerosi computer e macchine inoltrano i messaggi HTTP. A causa della struttura a strati dello stack Web, la maggior parte di questi opera a livello di trasporto, rete o fisico, diventando trasparente a livello HTTP e potenzialmente avendo un impatto significativo sulle prestazioni. Quelli che operano a livello di applicazione sono generalmente chiamati proxy. Possono essere trasparenti, inoltrando le richieste che ricevono senza modificarle in alcun modo, o non trasparenti, nel qual caso modificheranno la richiesta in qualche modo prima di passarla al server. I proxy possono svolgere numerose funzioni:

caching (la cache può essere pubblica o privata, come la cache del browser)
filtraggio (come una scansione antivirus o controlli parentali)
bilanciamento del carico (per consentire a più server di servire richieste diverse)
autenticazione (per controllare l’accesso a risorse diverse)
logging (consentendo l’archiviazione di informazioni storiche)

Aspetti di base di HTTP

HTTP è semplice

HTTP è generalmente progettato per essere semplice e leggibile dagli esseri umani, anche con la complessità aggiunta introdotta in HTTP/2 incapsulando i messaggi HTTP in frame. I messaggi HTTP possono essere letti e compresi dagli esseri umani, fornendo test più semplici per gli sviluppatori e una complessità ridotta per i nuovi arrivati.

HTTP è estensibile

Introdotte in HTTP/1.0, le intestazioni HTTP rendono questo protocollo facile da estendere e sperimentare. Nuove funzionalità possono anche essere introdotte da un semplice accordo tra un client e un server sulla semantica di una nuova intestazione.

HTTP è senza stato, ma non senza sessione

HTTP è senza stato: non c’è alcun collegamento tra due richieste eseguite in successione sulla stessa connessione. Ciò ha immediatamente la prospettiva di essere problematico per gli utenti che tentano di interagire con determinate pagine in modo coerente, ad esempio, utilizzando carrelli della spesa di e-commerce. Ma mentre il nucleo di HTTP stesso è senza stato, i cookie HTTP consentono l’uso di sessioni con stato. Utilizzando l’estendibilità dell’intestazione, i cookie HTTP vengono aggiunti al flusso di lavoro, consentendo la creazione di sessioni su ogni richiesta HTTP per condividere lo stesso contesto o lo stesso stato.

HTTP e connessioni

Una connessione è controllata a livello di trasporto e quindi fondamentalmente fuori dall’ambito di HTTP. HTTP non richiede che il protocollo di trasporto sottostante sia basato sulla connessione; richiede solo che sia affidabile o che non perda messaggi (almeno, presentando un errore in tali casi). Tra i due protocolli di trasporto più comuni su Internet, TCP è affidabile e UDP non lo è. HTTP si basa quindi sullo standard TCP, che è basato sulla connessione.

Prima che un client e un server possano scambiare una coppia richiesta/risposta HTTP, devono stabilire una connessione TCP, un processo che richiede diversi round-trip. Il comportamento predefinito di HTTP/1.0 è quello di aprire una connessione TCP separata per ogni coppia richiesta/risposta HTTP. Questo è meno efficiente rispetto alla condivisione di una singola connessione TCP quando più richieste vengono inviate in rapida successione.

Per mitigare questo difetto, HTTP/1.1 ha introdotto il pipelining (che si è rivelato difficile da implementare) e le connessioni persistenti: la connessione TCP sottostante può essere parzialmente controllata tramite l’intestazione Connection. HTTP/2 ha fatto un ulteriore passo avanti multiplexando i messaggi su una singola connessione, aiutando a mantenere la connessione attiva e più efficiente.

Sono in corso esperimenti per progettare un protocollo di trasporto migliore più adatto a HTTP. Ad esempio, Google sta sperimentando QUIC che si basa su UDP per fornire un protocollo di trasporto più affidabile ed efficiente.

Cosa può essere controllato da HTTP

Questa natura estensibile di HTTP ha, nel tempo, consentito un maggiore controllo e funzionalità del Web. I metodi di cache e autenticazione erano funzioni gestite all’inizio della storia di HTTP. La possibilità di allentare il vincolo di origine, al contrario, è stata aggiunta solo negli anni 2010.

Ecco un elenco di funzionalità comuni controllabili con HTTP:

Caching: il modo in cui i documenti vengono memorizzati nella cache può essere controllato da HTTP. Il server può istruire proxy e client su cosa memorizzare nella cache e per quanto tempo. Il client può istruire i proxy della cache intermedi a ignorare il documento archiviato. Allentamento del vincolo di origine: per impedire lo spionaggio e altre violazioni della privacy, i browser Web impongono una rigida separazione tra i siti Web. Solo le pagine dalla stessa origine possono accedere a tutte le informazioni di una pagina Web. Sebbene tale vincolo sia un peso per il server, le intestazioni HTTP possono allentare questa rigida separazione sul lato server, consentendo a un documento di diventare un patchwork di informazioni provenienti da domini diversi; potrebbero esserci anche motivi di sicurezza per farlo.
Autenticazione: alcune pagine possono essere protette in modo che solo utenti specifici possano accedervi. L’autenticazione di base può essere fornita da HTTP, utilizzando le intestazioni WWW-Authenticate e simili, oppure impostando una sessione specifica utilizzando i cookie HTTP.
Proxy e tunneling: i server o i client si trovano spesso su intranet e nascondono il loro vero indirizzo IP agli altri computer. Le richieste HTTP passano quindi attraverso i proxy per attraversare questa barriera di rete. Non tutti i proxy sono proxy HTTP. Il protocollo SOCKS, ad esempio, opera a un livello inferiore. Altri protocolli, come ftp, possono essere gestiti da questi proxy.
Sessioni: l’utilizzo di cookie HTTP consente di collegare le richieste allo stato del server. Ciò crea sessioni, nonostante l’HTTP di base sia un protocollo senza stato. Ciò è utile non solo per i carrelli della spesa dell’e-commerce, ma anche per qualsiasi sito che consenta la configurazione utente dell’output.

Flusso HTTP

Quando un client desidera comunicare con un server, sia il server finale che un proxy intermedio, esegue i seguenti passaggi:

Apri una connessione TCP: la connessione TCP viene utilizzata per inviare una richiesta, o più, e ricevere una risposta. Il client può aprire una nuova connessione, riutilizzare una connessione esistente o aprire più connessioni TCP ai server.
Invia un messaggio HTTP: i messaggi HTTP (prima di HTTP/2) sono leggibili dall’uomo. Con HTTP/2, questi semplici messaggi sono incapsulati in frame, rendendoli leggibile direttamente, ma il principio rimane lo stesso. Ad esempio:
```
HTTP
Copy to Clipboard
GET / HTTP/1.1
Host: wp-hosting.it
Accept-Language: it
```

Leggi la risposta inviata dal server, ad esempio:

HTTP
Copy to Clipboard
HTTP/1.1 200 OK
Date: Fri, 09 Aug 2019 15:56:01 GMT
Server: Apache
Last-Modified: Sat, 10 Aug 2019 18:21:02 GMT
ETag: "73384bc1-8995-789b055b1891b"
Accept-Ranges: bytes
Content-Length: 59721
Content-Type: text/html

<!doctype html>… (here come the 59721 bytes of the requested web page)

Chiudi o riutilizza la connessione per ulteriori richieste.

Se si attiva l’HTTP pipelining, è possibile inviare diverse richieste senza attendere che la prima risposta venga completamente ricevuta. L’HTTP pipelining si è dimostrato difficile da implementare nelle reti esistenti, dove vecchi software coesistono con versioni moderne. L’HTTP pipelining è stato sostituito in HTTP/2 con richieste di multiplexing più robuste all’interno di un frame.

Messaggi HTTP

I messaggi HTTP, come definiti in HTTP/1.1 e precedenti, sono leggibili dall’uomo. In HTTP/2, questi messaggi sono incorporati in una struttura binaria, un frame, che consente ottimizzazioni come la compressione delle intestazioni e il multiplexing. Anche se solo una parte del messaggio HTTP originale viene inviata in questa versione di HTTP, la semantica di ogni messaggio non cambia e il client ricostituisce (virtualmente) la richiesta HTTP/1.1 originale. È quindi utile comprendere i messaggi HTTP/2 nel formato HTTP/1.1.

Esistono due tipi di messaggi HTTP, richieste e risposte, ognuno con il proprio formato.

Richieste

Un esempio di richiesta HTTP:

Le richieste sono composte dai seguenti elementi:

Un metodo HTTP, solitamente un verbo come GET, POST o un sostantivo come OPTIONS o HEAD che definisce l’operazione che il client desidera eseguire. In genere, un client desidera recuperare una risorsa (utilizzando GET) o pubblicare il valore di un modulo HTML (utilizzando POST), sebbene in altri casi potrebbero essere necessarie più operazioni.
Il percorso della risorsa da recuperare; l’URL della risorsa spogliata degli elementi ovvi dal contesto, ad esempio senza il protocollo (http://), il dominio (qui, developer.mozilla.org) o la porta TCP (qui, 80).
La versione del protocollo HTTP.
Intestazioni facoltative che trasmettono informazioni aggiuntive per i server.
Un corpo, per alcuni metodi come POST, simile a quelli nelle risposte, che contiene la risorsa inviata.

Risposte

Un esempio di risposta:

Panoramica di una risposta HTTP “200 OK” a una richiesta GET, incluse le intestazioni di risposta.

Le risposte sono composte dai seguenti elementi:

La versione del protocollo HTTP che seguono.
Un codice di stato, che indica se la richiesta ha avuto successo o meno e perché.
Un messaggio di stato, una breve descrizione non autorevole del codice di stato.
Intestazioni HTTP, come quelle per le richieste.
Facoltativamente, un corpo contenente la risorsa recuperata.
API basate su HTTP

L’API basata su HTTP più comunemente utilizzata è la Fetch API, che può essere utilizzata per effettuare richieste HTTP da JavaScript. La Fetch API sostituisce la XMLHttpRequest API.

Un’altra API, server-sent events, è un servizio unidirezionale che consente a un server di inviare eventi al client, utilizzando HTTP come meccanismo di trasporto. Utilizzando l’interfaccia EventSource, il client apre una connessione e stabilisce gestori di eventi. Il browser client converte automaticamente i messaggi che arrivano sul flusso HTTP in oggetti Evento appropriati. Quindi li consegna ai gestori di eventi che sono stati registrati per il tipo di eventi, se noto, o al gestore di eventi onmessage se non è stato stabilito alcun gestore di eventi specifico per il tipo.

Conclusione

HTTP è un protocollo estensibile facile da usare. La struttura client-server, combinata con la possibilità di aggiungere intestazioni, consente a HTTP di progredire insieme alle capacità estese del Web.

Sebbene HTTP/2 aggiunga un po’ di complessità incorporando messaggi HTTP in frame per migliorare le prestazioni, la struttura di base dei messaggi è rimasta la stessa da HTTP/1.0. Il flusso di sessione rimane di base, consentendo di analizzarlo e sottoporlo a debug con un