Protocollo HTTP
I messaggi scambiati tra client e Web Server rispettano le regole descritte dal protocollo HTTP.
Il protocollo prevede solo due diversi tipi di messaggio.
I messaggi generati dal client sono definiti HTTP Request. Il server contattato restituisce le informazioni in messaggi denominati HTTP Response.
In accordo con il paradigma generale client/server, il client è l’entità che inizia il processo, il server rappresenta invece l’entità responsabile di completare le richieste di servizio.
Ogni HTTP Request è organizzata per linee.
La prima linea, denominata Request Line, riporta:
- Request Method (che indica il metodo usato per la richiesta);
- Request Object (che identifica l’informazione richiesta);
- Version (che specifica la versione del protocollo supportata dal client).
Dopo la prima linea è prevista un’intestazione per consentire al client di trasferire, assieme all’oggetto della richiesta, un insieme di informazioni complementari.
Il corpo della richiesta, quando presente, deve essere separato dall’intestazione da una linea lasciata intenzionalmente bianca.
I metodi fondamentali usati dal client per inviare una HTTP Request sono due: GET e POST.
In entrambi i casi il Web Server deve restituire al client l’oggetto associato all’URL specificato.
Si utilizza il metodo GET quando il corpo della richiesta è vuoto.
Eventuali informazioni da passare al server possono essere inserite in tal caso nella Request Line appendendole al’URL, usando la sintassi descritta nella RFC 3986 (metodo definito URL encoding).
Si usa il metodo POST quando occorre un Body per inserire informazioni che per dimensione o natura non possono essere inserite nell’intestazione del messaggio.
Esistono altri metodi, anche se scarsamente utilizzati:
- HEAD (formalmente coincide con GET ma il server deve restituire solo l’intestazione della risposta);
- PUT (per indicare al server di memorizzare l’oggetto allegato alla Request all’URL specificato);
- DELETE (per indicare al server di rimuovere l’oggetto memorizzato all’URL specificato);
- TRACE (permette di instaurare un loop a livello applicativo nel server, in modo da consentire al client di ricevere indietro una replica delle informazioni spedite al server);
- CONNECT (viene utilizzato in presenza di Proxy Server per richiedere il tunneling di una connessione HTTP attraverso un canale TLS/SSL).
Anche se sono attivati per default sui principali software utilizzati come Web Server, per motivi di sicurezza è consigliabile disabilitare i metodi PUT, DELETE e TRACE, su ogni Web Server accessibile a utenti dell’Internet pubblica.
L’intestazione di una HTTP Request contiene generalmente i seguenti campi:
- User-Agent (indica nome e versione del software utilizzato dall’utente per accedere al servizio);
- Accept-File (stabilisce quali tipi di file sono accettati dal client);
- Accept-Language (stabilisce la lingua accettata dal client);
- Accept-Encoding (stabilisce il metodo di compressione delle informazioni accettato dal client);
- Refer (riporta il riferimento al documento visualizzato dall’utente al momento della richiesta di servizio);
- If-Modified-Since (riporta una indicazione temporale per stabilire se il server deve restituire o meno l’informazione richiesta);
- Content-Length (se presente, stabilisce la lunghezza in byte del corpo del messaggio);
- Authorization (contiene eventuali dati per autenticare l’utente prima di accedere ai servizi del server).
Ogni HTTP Response è organizzata per linee.
La prima linea (denominata Status Line) riporta:
- Version (che specifica la versione del protocollo supportata dal server);
- Response Code (codice che specifica l’esito della richiesta);
- Response Phrase (utilizzato come descrizione del codice precedente).
Dopo la prima linea è prevista un’intestazione per consentire al server di trasferire un insieme di informazioni complementari ai dati contenuti nel corpo del messaggio.
Il corpo della risposta deve essere separato dall’intestazione da una linea lasciata intenzionalmente bianca.
Il protocollo HTTP supporta gli stessi tipi di dati definiti dallo standard MIME.
La maggior parte dei documenti associati al servizio WWW è comunque realizzata in accordo con il linguaggio ipertestuale HTML.
Il tipo MIME per tali documenti è text/html.
Nell’intestazione di una generica HTTP Response possono essere presenti i seguenti campi:
- Server (indica nome e versione del software utilizzato dal gestore quale Web Server);
- MIME-Version (fissa la versione dello standard MIME supportata dal server);
- Content-Type (definisce il tipo MIME relativo ai dati trasportati nel corpo della risposta);
- Content-Language (stabilisce la lingua utilizzata nel documento trasportato nel corpo della risposta);
- Content-Encoding (stabilisce il metodo di compressione delle informazioni utilizzato dal server);
- Content-Length (stabilisce la lunghezza in byte del corpo);
- Date (contiene l’indicazione temporale relativa all’istante di generazione della risposta);
- Last-Modified (contiene l’indicazione temporale relativa alla data dell’ultima modifica del documento presente nel corpo della risposta);
- Expires (contiene l’indicazione temporale relativa alla data in cui il documento trasportato deve essere considerato non più valido);
- WWW-Authenticate (indica la necessità di autenticare l’utente prima di poter trasferire l’oggetto richiesto, accesso controllato alle informazioni).
La versione 1.0 del protocollo HTTP prevede che dopo ogni risposta, la connessione TCP tra client e server venga chiusa.
Con tale approccio, nell’eventualità di dover trasferire più oggetti memorizzati nello stesso Web Server, è necessario negoziare molteplici connessioni TCP, utilizzando la stessa porta riservata 80/tcp.
Questo meccanismo, seppur in origine motivato dal desiderio di mantenere estremamente semplice il protocollo HTTP e le componenti software chiamate a implementarlo, può risultare poco efficiente per la trasmissione di documenti HTML, contenenti riferimenti a oggetti che devono essere visualizzati contemporaneamente sul browser dell’utente (immagini in linea, elementi di codice).
Per ridurre il carico di rete e migliorare la fruizione delle informazioni il browser utente è configurato per non inviare richieste di trasmissione per file già presenti in cache locale.
Anche con questo accorgimento il processo di download di una pagina multimediale può comunque risultare lento e/o incompleto, a causa del ritardo accumulato nell’acquisizione di uno o più elementi tra quelli da visualizzare.
La versione più recente del protocollo HTTP (versione 1.1) ha introdotto la possibilità di mantenere attiva una stessa sessione TCP attraverso la quale trasferire più oggetti.
In tal caso le Request e le Response HTTP restituite sono trasmesse una di seguito all’altra attraverso la stessa sessione TCP.
Questo approccio riduce, non solo il sovraccarico relativo alla negoziazione di nuove sessioni TCP, ma permette di associare i parametri negoziati tra partecipanti a tutti gli oggetti appartenenti a uno stesso flusso di dati (funzione che risulta molto utile nel caso di negoziazione di parametri crittografici per il mantenimento di un canale sicuro).
A parte la possibilità di riutilizzare una connessione TCP per trasferire molteplici oggetti, il protocollo HTTP è fondamentalmente stateless.
Per questo molti sviluppatori software hanno tratto vantaggio dall’utilizzo di quelli che vengono denominati HTTP Cookie.
I cookie rappresentano un contenitore in cui un server può inserire informazioni aggiuntive di cui è richiesta memorizzazione presso il browser.
Le informazioni memorizzate sul browser vengono associate all’URL che ha prodotto il Cookie.
Il programma client per default è configurato per accettare ogni Cookie prodotto dai server contattati, e per restituire il valore memorizzato alla prossima richiesta di accesso al medesimo URL.
