1. Introduction (Introduzione)
1.1 Purpose (Scopo)
Il protocollo di trasferimento ipertestuale (Hypertext Transfer Protocol, HTTP) è un protocollo a livello applicazione per sistemi informativi distribuiti, collaborativi e ipermediali. HTTP è stato utilizzato dall'iniziativa di informazione globale del World-Wide Web dal 1990. La prima versione di HTTP, chiamata HTTP/0.9, era un protocollo semplice per il trasferimento di dati grezzi attraverso Internet. HTTP/1.0, definito in RFC 1945 [6], ha migliorato il protocollo consentendo ai messaggi di adottare un formato di tipo MIME, contenente metadati sui dati trasferiti e modificatori per la semantica richiesta/risposta. Tuttavia, HTTP/1.0 non ha considerato adeguatamente gli effetti dei proxy gerarchici, della cache, della necessità di connessioni persistenti o degli host virtuali. Inoltre, molte applicazioni con implementazioni incomplete si definivano "HTTP/1.0", rendendo necessario un cambio di versione del protocollo affinché due applicazioni comunicanti potessero determinare le reali capacità reciproche.
Questa specifica definisce il protocollo denominato "HTTP/1.1". Questo protocollo include requisiti più rigorosi rispetto a HTTP/1.0 per garantire un'implementazione affidabile delle sue funzionalità.
I sistemi informativi pratici richiedono più funzionalità del semplice recupero, incluse ricerca, aggiornamenti frontend e annotazioni. HTTP consente un insieme aperto di metodi e campi di intestazione per indicare lo scopo di una richiesta [47]. Si basa sulla specifica di riferimento fornita dall'Uniform Resource Identifier (URI) [3], come posizione (URL) [4] o nome (URN) [20], per indicare la risorsa a cui deve essere applicato il metodo. I messaggi vengono trasmessi in un formato simile a quello utilizzato dalla posta Internet [9], come definito dalle Multipurpose Internet Mail Extensions (MIME) [7].
HTTP è anche utilizzato come protocollo generico per la comunicazione tra agenti utente e proxy/gateway verso altri sistemi Internet, inclusi quelli supportati dai protocolli SMTP [16], NNTP [13], FTP [18], Gopher [2] e WAIS [10]. In questo modo, HTTP consente un accesso ipermediale di base alle risorse disponibili da varie applicazioni.
1.2 Requirements (Requisiti)
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in RFC 2119 [34].
Un'implementazione non è conforme se non soddisfa uno o più dei requisiti di livello MUST o REQUIRED del protocollo che implementa. Un'implementazione che soddisfa tutti i requisiti di livello MUST o REQUIRED e tutti i requisiti di livello SHOULD del suo protocollo è detta "incondizionatamente conforme" (unconditionally compliant). Un'implementazione che soddisfa tutti i requisiti di livello MUST ma non tutti i requisiti di livello SHOULD del suo protocollo è detta "condizionatamente conforme" (conditionally compliant).
1.3 Terminology (Terminologia)
Questa specifica utilizza numerosi termini per indicare i ruoli svolti dai partecipanti e dagli oggetti nella comunicazione HTTP.
connection (connessione) Un circuito virtuale a livello di trasporto stabilito tra due programmi per scopi di comunicazione.
message (messaggio) L'unità di base della comunicazione HTTP, costituita da una sequenza strutturata di ottetti conforme alla sintassi definita nella sezione 4 e trasmessa tramite una connessione.
request (richiesta) Un messaggio di richiesta HTTP, come definito nella sezione 5.
response (risposta) Un messaggio di risposta HTTP, come definito nella sezione 6.
resource (risorsa) Un oggetto dati di rete o un servizio che può essere identificato da un URI, come definito nella sezione 3.2. Le risorse possono essere disponibili in più rappresentazioni (ad esempio, più lingue, formati di dati, dimensioni e risoluzioni) o variare in altri modi.
entity (entità) Le informazioni trasferite come payload di una richiesta o risposta. Un'entità è composta da metadati sotto forma di campi di intestazione dell'entità e contenuto sotto forma di corpo dell'entità, come descritto nella sezione 7.
representation (rappresentazione) Un'entità inclusa in una risposta soggetta a negoziazione del contenuto, come descritto nella sezione 12. Potrebbero esserci più rappresentazioni associate a un particolare stato di risposta.
content negotiation (negoziazione del contenuto) Il meccanismo per selezionare la rappresentazione appropriata quando si serve una richiesta, come descritto nella sezione 12. La rappresentazione delle entità in qualsiasi risposta può essere negoziata (incluse le risposte di errore).
variant (variante) Una risorsa può avere una o più rappresentazioni associate in un dato momento. Ciascuna di queste rappresentazioni è chiamata "variante" (variant). L'uso del termine "variante" non implica necessariamente che la risorsa sia soggetta a negoziazione del contenuto.
client (client) Un programma che stabilisce una connessione allo scopo di inviare richieste.
user agent (agente utente) Il client che avvia una richiesta. Questi sono tipicamente browser, editor, web crawler (web-traversing robots) o altri strumenti per utenti finali.
server (server) Un'applicazione che accetta connessioni per servire richieste inviando risposte. Qualsiasi programma può essere sia client che server. Il nostro uso di questi termini si riferisce solo al ruolo eseguito dal programma per una particolare connessione, piuttosto che alle capacità generali del programma. Allo stesso modo, qualsiasi server può fungere da server di origine, proxy, gateway o tunnel, cambiando comportamento in base alla natura di ciascuna richiesta.
origin server (server di origine) Il server su cui risiede o deve essere creata una determinata risorsa.
proxy (proxy) Un programma intermediario che agisce sia come server che come client allo scopo di effettuare richieste per conto di altri client. Le richieste vengono elaborate internamente o trasmesse, possibilmente con traduzione, ad altri server. Un proxy deve (MUST) implementare sia i requisiti client che server di questa specifica. Un "proxy trasparente" (transparent proxy) è un proxy che non modifica la richiesta o la risposta oltre quanto richiesto per l'autenticazione e l'identificazione del proxy. Un "proxy non trasparente" (non-transparent proxy) è un proxy che modifica la richiesta o la risposta per fornire alcuni servizi aggiuntivi all'agente utente, come un servizio di annotazione di gruppo, conversione del tipo di media, riduzione del protocollo o filtraggio dell'anonimato. A meno che non sia esplicitamente indicato un comportamento trasparente o non trasparente, i requisiti del proxy HTTP si applicano a entrambi i tipi di proxy.
gateway (gateway) Un server che agisce come intermediario per un altro server. A differenza di un proxy, un gateway riceve richieste come se fosse il server di origine per la risorsa richiesta. Il client richiedente potrebbe non essere consapevole di stare comunicando con un gateway.
tunnel (tunnel) Un programma intermediario che agisce come relay cieco tra due connessioni. Una volta attivo, un tunnel non è considerato parte della comunicazione HTTP, sebbene un tunnel possa essere stato avviato da una richiesta HTTP. Il tunnel cessa di esistere quando entrambe le estremità delle connessioni inoltrate sono chiuse.
cache (cache) La memorizzazione locale dei messaggi di risposta di un programma e il sottosistema che controlla la memorizzazione, il recupero e la cancellazione dei suoi messaggi. Una cache memorizza le risposte memorizzabili per ridurre il tempo di risposta e il consumo di larghezza di banda di rete per richieste equivalenti future. Qualsiasi client o server può includere una cache, sebbene un server che agisce come tunnel non possa utilizzare una cache.
cacheable (memorizzabile) Una risposta è memorizzabile se una cache è autorizzata a memorizzare una copia del messaggio di risposta da utilizzare per rispondere a richieste successive. Le regole per determinare se una risposta HTTP è memorizzabile sono definite nella sezione 13. Anche se una risorsa è memorizzabile, potrebbero esserci vincoli aggiuntivi sul fatto che una particolare cache debba memorizzarla.
first-hand (di prima mano) Una risposta è di prima mano se proviene dal server di origine, possibilmente attraverso uno o più proxy. Una risposta è anche di prima mano se la sua validità è stata verificata direttamente con il server di origine.
explicit expiration time (tempo di scadenza esplicito) Il momento in cui il server di origine intende che un'entità non venga più restituita da una cache senza ulteriore validazione.
heuristic expiration time (tempo di scadenza euristico) Un tempo di scadenza assegnato da una cache in assenza di un tempo di scadenza esplicito.
age (età) L'età di una risposta è il tempo trascorso da quando il server di origine ha inviato la risposta (o ha validato con successo la risposta).
freshness lifetime (durata della freschezza) La durata tra la generazione di una risposta e il suo tempo di scadenza.
fresh (fresco) Una risposta è fresca se la sua età non ha ancora superato la sua durata di freschezza.
stale (stantio) Una risposta è stantia se la sua età ha superato la sua durata di freschezza.
semantically transparent (semanticamente trasparente) Una cache si comporta in modo semanticamente trasparente quando il suo utilizzo non influisce né sul client richiedente né sul server di origine, se non per migliorare le prestazioni. Quando una cache opera in modo semanticamente trasparente, il client riceve esattamente la stessa risposta (eccetto i campi di intestazione hop-by-hop) che avrebbe ricevuto se fosse stata inviata direttamente dal server di origine, e la cache non influisce sull'elaborazione delle richieste successive.
validator (validatore) Un elemento di protocollo (ad esempio, un tag di entità o un tempo Last-Modified) utilizzato per determinare se una voce di cache è una copia equivalente di un'entità.
upstream/downstream (a monte/a valle) A monte e a valle descrivono il flusso dei messaggi: tutti i messaggi fluiscono da monte a valle.
inbound/outbound (in entrata/in uscita) In entrata e in uscita si riferiscono ai percorsi di richiesta e risposta rispetto alla richiesta: "in entrata" significa "verso il server di origine", e "in uscita" significa "verso l'agente utente".
1.4 Overall Operation (Operazione Complessiva)
Il protocollo HTTP è un protocollo richiesta/risposta. Un client invia una richiesta a un server sotto forma di metodo di richiesta, URI e versione del protocollo, seguita da un messaggio di tipo MIME contenente modificatori di richiesta, informazioni sul client e possibilmente contenuto del corpo, trasmesso tramite una connessione. Il server risponde con una riga di stato, includendo la versione del protocollo del messaggio e un codice di successo o errore, seguita da un messaggio di tipo MIME contenente informazioni sul server, metadati dell'entità e possibilmente contenuto del corpo dell'entità. La maggior parte della comunicazione HTTP è avviata da un agente utente e consiste in una richiesta per una risorsa su un server di origine. Nel caso più semplice, questo può essere realizzato tramite una singola connessione (v) tra l'agente utente (UA) e il server di origine (O).
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
Una situazione più complessa si verifica quando sono presenti uno o più intermediari nella catena richiesta/risposta. Ci sono tre forme comuni di intermediari: proxy, gateway e tunnel. Un proxy è un agente di inoltro che riceve richieste per un URI nella sua forma assoluta, riscrive tutto o parte del messaggio e inoltra la richiesta riformattata verso il server identificato dall'URI. Un gateway è un agente ricevente che agisce come uno strato sopra un altro server e, se necessario, può tradurre le richieste nel protocollo del server sottostante. Un tunnel agisce come punto di relay tra due connessioni senza modificare i messaggi. I tunnel vengono utilizzati quando la comunicazione deve passare attraverso un intermediario (come un firewall), anche se l'intermediario non può comprendere il contenuto dei messaggi.
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
La figura sopra mostra tre intermediari (A, B e C) tra l'agente utente e il server di origine. Un messaggio che attraversa l'intera catena richiesta/risposta utilizza il meccanismo di passaggio delle opzioni di comunicazione HTTP per determinare i parametri della connessione.
Qualsiasi parte che non agisce come tunnel può utilizzare una cache per soddisfare le richieste. L'effetto di una cache sulla catena richiesta/risposta dipende dai requisiti di caching delle varie cache lungo la catena che potrebbero intercettare la richiesta o la risposta. Il comportamento di caching e le risposte memorizzabili sono definiti nella sezione 13.
In pratica, esistono varie configurazioni di modelli architetturali su Internet e all'interno delle organizzazioni. Ad esempio, un "provider di accesso nazionale" utilizza tipicamente grandi cache proxy in modo che più agenti utente possano accedere ai server di origine attraverso la stessa catena di richieste. Un'altra configurazione comune è la cache "reverse proxy", che si trova sotto il nome host di un'organizzazione ma è controllata dai suoi client o da terzi. Le cache reverse proxy sono trasparenti per gli agenti utente ma sono spesso gestite dai provider di rete per risparmiare traffico attraverso la rete.
La comunicazione HTTP si verifica tipicamente su connessioni TCP/IP. La porta predefinita è TCP 80 [19], ma possono essere utilizzate anche altre porte. Questo non preclude l'implementazione di HTTP su altri protocolli su Internet o su altre reti. HTTP presume solo un trasporto affidabile. Qualsiasi protocollo che fornisca tali garanzie può essere utilizzato. La mappatura delle strutture di richiesta e risposta HTTP/1.1 sulle unità dati di un dato protocollo di trasporto è al di fuori dell'ambito di questa specifica.
In HTTP/1.0, la maggior parte delle implementazioni chiudeva la connessione dopo ogni scambio richiesta/risposta. In HTTP/1.1, un meccanismo consente di utilizzare la stessa connessione per più scambi richiesta/risposta, come descritto nella sezione 8.1, utilizzando "connessioni persistenti" (persistent connections).