3. Terminology and Core Concepts (Terminologia e concetti di base)
HTTP è stato creato per l'architettura del World Wide Web (WWW) e si è evoluto nel tempo per supportare le esigenze di scalabilità di un sistema ipertestuale mondiale. Gran parte di questa architettura si riflette nella terminologia utilizzata per definire HTTP.
3.1. Resources (Risorse)
Il target di una richiesta HTTP è chiamato "risorsa" (Resource). HTTP non limita la natura di una risorsa; definisce semplicemente un'interfaccia che potrebbe essere utilizzata per interagire con le risorse. La maggior parte delle risorse è identificata da un Uniform Resource Identifier (URI), come descritto nella sezione 4.
Uno degli obiettivi di progettazione di HTTP è separare l'identificazione della risorsa dalla semantica della richiesta, il che è reso possibile assegnando la semantica della richiesta al metodo di richiesta (sezione 9) e ad alcuni campi di intestazione che modificano la richiesta. Una risorsa non può trattare una richiesta in modo incoerente con la semantica del metodo della richiesta. Ad esempio, sebbene l'URI di una risorsa possa implicare una semantica non sicura, un client può aspettarsi che la risorsa eviti azioni non sicure durante l'elaborazione di una richiesta con un metodo sicuro (Safe Method) (vedere sezione 9.2.1).
HTTP si basa sullo standard Uniform Resource Identifier (URI) [URI] per indicare la risorsa target (sezione 7.1) e le relazioni tra le risorse.
3.2. Representations (Rappresentazioni)
Una "rappresentazione" (Representation) è un'informazione destinata a riflettere uno stato passato, corrente o desiderato di una determinata risorsa, in un formato che può essere facilmente comunicato tramite il protocollo. Una rappresentazione è composta da un insieme di metadati di rappresentazione (Representation Metadata) e da un flusso potenzialmente illimitato di dati di rappresentazione (Representation Data, sezione 8).
HTTP consente il "nascondimento delle informazioni" (Information Hiding) dietro la sua interfaccia uniforme definendo la comunicazione rispetto a una rappresentazione trasferibile dello stato della risorsa, piuttosto che trasferire la risorsa stessa. Ciò consente alla risorsa identificata da un URI di essere qualsiasi cosa, comprese funzioni temporali come "il tempo attuale a Laguna Beach", fornendo potenzialmente informazioni che rappresentano quella risorsa nel momento in cui viene generato un messaggio [REST].
L'interfaccia uniforme è simile a una finestra attraverso la quale si può osservare e agire su qualcosa solo attraverso la comunicazione di messaggi a un attore indipendente dall'altra parte. È necessaria un'astrazione condivisa per rappresentare ("prendere il posto di") lo stato corrente o desiderato di quella cosa nelle nostre comunicazioni. Quando una rappresentazione è un ipertesto, può fornire sia una rappresentazione dello stato della risorsa sia istruzioni di elaborazione che aiutano a guidare le future interazioni del destinatario.
Una risorsa target potrebbe essere fornita con, o essere in grado di generare, più rappresentazioni che sono ciascuna destinata a riflettere lo stato corrente della risorsa. Un algoritmo, solitamente basato sulla negoziazione del contenuto (Content Negotiation, sezione 12), verrebbe utilizzato per selezionare una di queste rappresentazioni come la più applicabile a una determinata richiesta. Questa "rappresentazione selezionata" (Selected Representation) fornisce i dati e i metadati per valutare le richieste condizionali (sezione 13) e costruire il contenuto per le risposte 200 (OK), 206 (Partial Content) e 304 (Not Modified) a GET (sezione 9.3.1).
3.3. Connections, Clients, and Servers (Connessioni, client e server)
HTTP è un protocollo client/server che opera su una "connessione" (Connection) affidabile di livello trasporto o sessione.
Un "client" (Client) HTTP è un programma che stabilisce una connessione a un server allo scopo di inviare una o più richieste HTTP. Un "server" (Server) HTTP è un programma che accetta connessioni per servire richieste HTTP inviando risposte HTTP.
I termini client e server si riferiscono solo ai ruoli che questi programmi svolgono per una particolare connessione. Lo stesso programma potrebbe agire come client su alcune connessioni e come server su altre.
HTTP è definito come un protocollo senza stato (Stateless Protocol), il che significa che la semantica di ogni messaggio di richiesta può essere compresa isolatamente e che la relazione tra connessioni e messaggi su di esse non ha impatto sull'interpretazione di tali messaggi. Ad esempio, una richiesta CONNECT (sezione 9.3.6) o una richiesta con il campo di intestazione Upgrade (sezione 7.8) può verificarsi in qualsiasi momento, non solo nel primo messaggio su una connessione. Molte implementazioni dipendono dal design senza stato di HTTP per riutilizzare le connessioni proxy o bilanciare dinamicamente il carico delle richieste su più server.
Di conseguenza, un server non deve (MUST NOT) presumere che due richieste sulla stessa connessione provengano dallo stesso agente utente a meno che la connessione non sia protetta e specifica per quell'agente. Alcune estensioni HTTP non standard (ad esempio, [RFC4559]) sono note per violare questo requisito, causando problemi di sicurezza e interoperabilità.
3.4. Messages (Messaggi)
HTTP è un protocollo senza stato di richiesta/risposta per lo scambio di "messaggi" (Messages) su una connessione. I termini "mittente" (Sender) e "destinatario" (Recipient) si riferiscono a qualsiasi implementazione che invia o riceve un determinato messaggio, rispettivamente.
Un client invia richieste a un server sotto forma di messaggio di "richiesta" (Request) con un metodo (sezione 9) e un target di richiesta (sezione 7.1). La richiesta potrebbe anche contenere campi di intestazione (sezione 6.3) per modificatori di richiesta, informazioni sul client e metadati di rappresentazione, contenuto (sezione 6.4) destinato all'elaborazione in conformità con il metodo, e campi di coda (sezione 6.5) per comunicare informazioni raccolte durante l'invio del contenuto.
Un server risponde alla richiesta di un client inviando uno o più messaggi di "risposta" (Response), ciascuno includente un codice di stato (sezione 15). La risposta potrebbe anche contenere campi di intestazione per informazioni sul server, metadati della risorsa e metadati di rappresentazione, contenuto da interpretare in conformità con il codice di stato, e campi di coda per comunicare informazioni raccolte durante l'invio del contenuto.
3.5. User Agents (Agenti utente)
Il termine "agente utente" (User Agent) si riferisce a uno qualsiasi dei vari programmi client che avviano una richiesta.
La forma più familiare di agente utente è il browser Web generico, ma questa è solo una piccola percentuale delle implementazioni. Altri agenti utente comuni includono spider (robot di attraversamento del Web), strumenti da riga di comando, schermi pubblicitari, elettrodomestici, bilance, lampadine, script di aggiornamento firmware, app mobili e dispositivi di comunicazione in una moltitudine di forme e dimensioni.
Essere un agente utente non implica che ci sia un utente umano che interagisce direttamente con l'agente software al momento di una richiesta. In molti casi, un agente utente è installato o configurato per funzionare in background e salvare i suoi risultati per un'ispezione successiva (o salvare solo un sottoinsieme di quei risultati che potrebbero essere interessanti o errati). Gli spider, ad esempio, ricevono tipicamente un URI di partenza e sono configurati per seguire determinati comportamenti durante l'attraversamento del Web come grafico ipertestuale.
Molti agenti utente non possono, o scelgono di non, fare suggerimenti interattivi al loro utente o fornire adeguati avvertimenti per problemi di sicurezza o privacy. Nei pochi casi in cui questa specifica richiede la segnalazione di errori all'utente, è accettabile che tale segnalazione sia osservabile solo in una console di errore o in un file di log. Allo stesso modo, i requisiti che un'azione automatizzata debba essere confermata dall'utente prima di procedere potrebbero essere soddisfatti tramite scelte di configurazione anticipate, opzioni di runtime o semplice evitamento dell'azione non sicura; la conferma non implica alcuna interfaccia utente specifica o interruzione del normale processo se l'utente ha già effettuato tale scelta.
3.6. Origin Server (Server di origine)
Il termine "server di origine" (Origin Server) si riferisce a un programma che può originare risposte autorevoli (Authoritative Responses) per una determinata risorsa target.
La forma più familiare di server di origine sono i grandi siti Web pubblici. Tuttavia, proprio come gli agenti utente vengono equiparati ai browser, è facile essere fuorviati pensando che tutti i server di origine siano simili. I server di origine comuni includono anche unità di automazione domestica, componenti di rete configurabili, macchine per ufficio, robot autonomi, feed di notizie, telecamere del traffico, selettori di annunci in tempo reale e piattaforme di video on demand.
La maggior parte delle comunicazioni HTTP consiste in una richiesta di recupero (GET) per una rappresentazione di una risorsa identificata da un URI. Nel caso più semplice, ciò potrebbe essere realizzato tramite una singola connessione bidirezionale (===) tra l'agente utente (UA) e il server di origine (O).
request >
UA ======================================= O
< response
Figura 1
3.7. Intermediaries (Intermediari)
HTTP consente l'uso di intermediari (Intermediaries) per soddisfare le richieste attraverso una catena di connessioni. Esistono tre forme comuni di "intermediario" HTTP: proxy, gateway e tunnel. In alcuni casi, un singolo intermediario potrebbe agire come server di origine, proxy, gateway o tunnel, cambiando comportamento in base alla natura di ciascuna richiesta.
> > > >
UA =========== A =========== B =========== C =========== O
< < < <
Figura 2
La figura sopra mostra tre intermediari (A, B e C) tra l'agente utente e il server di origine. Un messaggio di richiesta o risposta che attraversa l'intera catena passerà attraverso quattro connessioni separate. Alcune opzioni di comunicazione HTTP potrebbero applicarsi solo alla connessione con il vicino non-tunnel più vicino, solo agli endpoint della catena, o a tutte le connessioni lungo la catena. Sebbene il diagramma sia lineare, ogni partecipante potrebbe essere impegnato in più comunicazioni simultanee. Ad esempio, B potrebbe ricevere richieste da molti client diversi da A, e/o inoltrare richieste a server diversi da C, allo stesso tempo in cui sta gestendo la richiesta di A. Allo stesso modo, richieste successive potrebbero essere inviate attraverso un percorso diverso di connessioni, spesso basato sulla configurazione dinamica per il bilanciamento del carico.
I termini "upstream" (a monte) e "downstream" (a valle) sono utilizzati per descrivere i requisiti direzionali in relazione al flusso dei messaggi: tutti i messaggi fluiscono da upstream a downstream. I termini "inbound" (in entrata) e "outbound" (in uscita) sono utilizzati per descrivere i requisiti direzionali in relazione al percorso della richiesta: inbound significa "verso il server di origine", mentre outbound significa "verso l'agente utente".
Un "proxy" (Proxy) è un agente di inoltro messaggi che viene scelto dal client, di solito tramite regole di configurazione locali, per ricevere richieste per alcuni tipi di URI assoluti e tentare di soddisfare tali richieste tramite traduzione attraverso l'interfaccia HTTP. Alcune traduzioni sono minime, come per le richieste proxy per gli URI "http", mentre altre richieste potrebbero richiedere la traduzione da e verso protocolli di livello applicazione completamente diversi. I proxy sono spesso utilizzati per raggruppare le richieste HTTP di un'organizzazione attraverso un intermediario comune per servizi di sicurezza, servizi di annotazione o caching condiviso. Alcuni proxy sono progettati per applicare trasformazioni a messaggi o contenuti selezionati mentre vengono inoltrati, come descritto nella sezione 7.7.
Un "gateway" (Gateway) (noto anche come "proxy inverso" Reverse Proxy) è un intermediario che agisce come server di origine per la connessione in uscita ma traduce le richieste ricevute e le inoltra in entrata a un altro server o altri server. I gateway sono spesso utilizzati per incapsulare servizi informativi legacy o non affidabili, per migliorare le prestazioni del server attraverso il caching "acceleratore" (Accelerator) e per abilitare il partizionamento o il bilanciamento del carico dei servizi HTTP su più macchine.
Tutti i requisiti HTTP applicabili a un server di origine si applicano anche alla comunicazione in uscita di un gateway. Un gateway comunica con i server in entrata utilizzando qualsiasi protocollo desideri, comprese estensioni private a HTTP che sono al di fuori dell'ambito di questa specifica. Tuttavia, un gateway HTTP-to-HTTP che desidera interoperare con server HTTP di terze parti deve conformarsi ai requisiti dell'agente utente sulla connessione in entrata del gateway.
Un "tunnel" (Tunnel) agisce come un relè cieco tra due connessioni senza modificare i messaggi. Una volta attivo, un tunnel non è considerato una parte della comunicazione HTTP, sebbene il tunnel possa essere stato avviato da una richiesta HTTP. Un tunnel cessa di esistere quando entrambe le estremità della connessione relay sono chiuse. I tunnel sono utilizzati per estendere una connessione virtuale attraverso un intermediario, ad esempio quando Transport Layer Security (TLS, [TLS13]) viene utilizzato per stabilire una comunicazione confidenziale attraverso un proxy firewall condiviso.
Le categorie sopra per l'intermediario considerano solo quelli che agiscono come partecipanti alla comunicazione HTTP. Esistono anche intermediari che possono agire su livelli inferiori dello stack di protocolli di rete, filtrando o reindirizzando il traffico HTTP senza la conoscenza o il permesso dei mittenti dei messaggi. Gli intermediari di rete sono indistinguibili (a livello di protocollo) da un attaccante on-path, spesso introducendo difetti di sicurezza o problemi di interoperabilità a causa della violazione errata della semantica HTTP.
Ad esempio, un "proxy di intercettazione" (Interception Proxy) [RFC3040] (comunemente noto anche come "proxy trasparente" Transparent Proxy [RFC1919]) differisce da un proxy HTTP perché non è scelto dal client. Invece, un proxy di intercettazione filtra o reindirizza i pacchetti TCP in uscita sulla porta 80 (e occasionalmente altro traffico di porte comuni). I proxy di intercettazione si trovano comunemente sui punti di accesso alla rete pubblica, come mezzo per imporre l'abbonamento all'account prima di consentire l'uso di servizi Internet non locali, e all'interno dei firewall aziendali per applicare le politiche di utilizzo della rete.
3.8. Caches (Cache)
Una "cache" (Cache) è un archivio locale di messaggi di risposta precedenti e il sottosistema che controlla la sua archiviazione, recupero ed eliminazione dei messaggi. Una cache memorizza risposte memorizzabili nella cache per ridurre il tempo di risposta e il consumo di larghezza di banda della rete su richieste future equivalenti. Qualsiasi client o server può (MAY) impiegare una cache, sebbene una cache non possa essere utilizzata mentre agisce come tunnel.
L'effetto di una cache è che la catena richiesta/risposta viene accorciata se uno dei partecipanti lungo la catena ha una risposta memorizzata nella cache applicabile a quella richiesta. Quanto segue illustra la catena risultante se B ha una copia memorizzata nella cache di una risposta precedente da O (tramite C) per una richiesta che non è stata memorizzata nella cache da UA o A.
> >
UA =========== A =========== B - - - - - - C - - - - - - O
< <
Figura 3
Una risposta è "memorizzabile nella cache" (Cacheable) se una cache è autorizzata a memorizzare una copia del messaggio di risposta per l'uso nella risposta a richieste successive. Anche quando una risposta è memorizzabile nella cache, potrebbero esserci vincoli aggiuntivi posti dal client o dal server di origine su quando quella risposta memorizzata nella cache può essere utilizzata per una particolare richiesta. I requisiti HTTP per il comportamento della cache e le risposte memorizzabili nella cache sono definiti in [CACHING].
Esiste un'ampia varietà di architetture e configurazioni di cache implementate in tutto il World Wide Web e all'interno di grandi organizzazioni. Queste includono gerarchie nazionali di cache proxy per risparmiare larghezza di banda e ridurre la latenza, reti di distribuzione dei contenuti che utilizzano il caching gateway per ottimizzare la distribuzione regionale e globale di siti popolari, sistemi collaborativi che trasmettono o multicast le voci della cache, archivi di voci della cache pre-recuperate per l'uso in ambienti offline o ad alta latenza, e così via.
3.9. Example Message Exchange (Esempio di scambio di messaggi)
Il seguente esempio illustra un tipico scambio di messaggi HTTP/1.1 per una richiesta GET (sezione 9.3.1) sull'URI http://www.example.com/hello.txt:
Richiesta del client:
GET /hello.txt HTTP/1.1
User-Agent: curl/7.64.1
Host: www.example.com
Accept-Language: en, mi
Risposta del server:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! My content includes a trailing CRLF.