1. Introduction (Introduzione)

1.1. Purpose (Scopo)

Il protocollo di trasferimento ipertestuale (Hypertext Transfer Protocol, HTTP) è una famiglia di protocolli senza stato (Stateless), a livello applicativo (Application-Level), di richiesta/risposta (Request/Response) che condividono un'interfaccia generica (Generic Interface), una semantica estensibile (Extensible Semantics) e messaggi auto-descrittivi (Self-Descriptive Messages) per consentire un'interazione flessibile con i sistemi di informazione ipertestuale basati sulla rete.

HTTP nasconde i dettagli di come viene implementato un servizio presentando un'interfaccia uniforme (Uniform Interface) ai client che è indipendente dai tipi di risorse fornite. Allo stesso modo, i server non devono essere a conoscenza dello scopo di ciascun client: una richiesta può essere considerata isolatamente piuttosto che essere associata a un tipo specifico di client o a una sequenza predeterminata di passaggi applicativi. Ciò consente l'uso efficace di implementazioni generiche in molti contesti diversi, riduce la complessità delle interazioni e consente un'evoluzione indipendente nel tempo.

HTTP è anche progettato per l'uso come protocollo di intermediazione (Intermediation Protocol), in cui i proxy (Proxies) e i gateway (Gateways) possono tradurre sistemi di informazione non-HTTP in un'interfaccia più generica.

Una conseguenza di questa flessibilità è che il protocollo non può essere definito in termini di ciò che accade dietro l'interfaccia. Invece, siamo limitati a definire la sintassi della comunicazione (Syntax of Communication), l'intento della comunicazione ricevuta (Intent) e il comportamento atteso dei destinatari (Expected Behavior). Se la comunicazione è considerata isolatamente, le azioni riuscite dovrebbero riflettersi nei corrispondenti cambiamenti all'interfaccia osservabile fornita dai server. Tuttavia, poiché più client potrebbero agire in parallelo e forse con scopi contrastanti, non possiamo richiedere che tali cambiamenti siano osservabili oltre l'ambito di una singola risposta.

1.2. History and Evolution (Storia ed evoluzione)

HTTP è stato il principale protocollo di trasferimento di informazioni per il World Wide Web sin dalla sua introduzione nel 1990. È iniziato come un meccanismo banale per richieste a bassa latenza, con un singolo metodo (GET) per richiedere il trasferimento di un presunto documento ipertestuale identificato da un dato percorso. Man mano che il Web cresceva, HTTP è stato esteso per racchiudere richieste e risposte all'interno di messaggi, trasferire formati di dati arbitrari utilizzando tipi di media (Media Types) simili a MIME e instradare le richieste attraverso intermediari (Intermediaries). Questi protocolli sono stati infine definiti come HTTP/0.9 e HTTP/1.0 (vedi [HTTP/1.0]).

HTTP/1.1 è stato progettato per perfezionare le funzionalità del protocollo mantenendo la compatibilità con la sintassi di messaggistica testuale esistente, migliorando la sua interoperabilità (Interoperability), scalabilità (Scalability) e robustezza (Robustness) su Internet. Ciò includeva delimitatori di dati basati sulla lunghezza (Length-Based Data Delimiters) per contenuti fissi e dinamici (chunked, Chunked), un framework coerente per la negoziazione del contenuto (Content Negotiation), validatori opachi (Opaque Validators) per richieste condizionali (Conditional Requests), controlli della cache (Cache Controls) per una migliore coerenza della cache, richieste di intervallo (Range Requests) per aggiornamenti parziali e connessioni persistenti (Persistent Connections) predefinite. HTTP/1.1 è stato introdotto nel 1995 e pubblicato sullo Standards Track nel 1997 [RFC2068], rivisto nel 1999 [RFC2616] e rivisto nuovamente nel 2014 ([RFC7230] fino a [RFC7235]).

HTTP/2 ([HTTP/2]) ha introdotto un livello di sessione multiplexato (Multiplexed Session Layer) sopra i protocolli TLS e TCP esistenti per scambiare messaggi HTTP concorrenti con compressione efficiente dei campi (Field Compression) e push del server (Server Push). HTTP/3 ([HTTP/3]) fornisce una maggiore indipendenza per i messaggi concorrenti utilizzando QUIC come trasporto multiplexato sicuro su UDP invece di TCP.

Tutte e tre le versioni principali di HTTP si basano sulla semantica definita da questo documento. Non si sono rese obsolete a vicenda perché ognuna ha vantaggi e limitazioni specifici a seconda del contesto d'uso. Le implementazioni dovrebbero scegliere il trasporto e la sintassi di messaggistica più appropriati per il loro contesto particolare.

Questa revisione di HTTP separa la definizione della semantica (questo documento) e del caching ([CACHING]) dalla sintassi di messaggistica HTTP/1.1 corrente ([HTTP/1.1]) per consentire a ciascuna versione principale del protocollo di progredire indipendentemente pur facendo riferimento alla stessa semantica di base.

1.3. Core Semantics (Semantica di base)

HTTP fornisce un'interfaccia uniforme per interagire con una risorsa (Resource, Sezione 3.1) - indipendentemente dal suo tipo, natura o implementazione - inviando messaggi che manipolano o trasferiscono rappresentazioni (Representations, Sezione 3.2).

Ogni messaggio è una richiesta (Request) o una risposta (Response). Un client costruisce messaggi di richiesta che comunicano le sue intenzioni e instrada questi messaggi verso un server di origine (Origin Server) identificato. Un server ascolta le richieste, analizza ogni messaggio ricevuto, interpreta la semantica del messaggio in relazione alla risorsa di destinazione (Target Resource) identificata e risponde a quella richiesta con uno o più messaggi di risposta. Il client esamina le risposte ricevute per vedere se le sue intenzioni sono state eseguite, determinando cosa fare successivamente in base ai codici di stato (Status Codes) e al contenuto ricevuti.

La semantica HTTP include le intenzioni definite da ciascun metodo di richiesta (Sezione 9), le estensioni a tali semantiche che potrebbero essere descritte nei campi di intestazione della richiesta (Request Header Fields), i codici di stato che descrivono la risposta (Sezione 15) e altri dati di controllo e metadati delle risorse (Resource Metadata) che potrebbero essere forniti nei campi di risposta.

La semantica include anche metadati di rappresentazione (Representation Metadata) che descrivono come il contenuto è destinato a essere interpretato da un destinatario, campi di intestazione della richiesta che potrebbero influenzare la selezione del contenuto e i vari algoritmi di selezione che sono collettivamente chiamati "negoziazione del contenuto" (Content Negotiation, Sezione 12).

1.4. Specifications Obsoleted by This Document (Specifiche rese obsolete da questo documento)

Titolo	Riferimento	Vedi
HTTP Over TLS	[RFC2818]	B.1
HTTP/1.1 Message Syntax and Routing [*]	[RFC7230]	B.2
HTTP/1.1 Semantics and Content	[RFC7231]	B.3
HTTP/1.1 Conditional Requests	[RFC7232]	B.4
HTTP/1.1 Range Requests	[RFC7233]	B.5
HTTP/1.1 Authentication	[RFC7235]	B.6
HTTP Status Code 308 (Permanent Redirect)	[RFC7538]	B.7
HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields	[RFC7615]	B.8
HTTP Client-Initiated Content-Encoding	[RFC7694]	B.9

Tabella 1

[*] Questo documento rende obsolete solo le parti di RFC 7230 che sono indipendenti dalla sintassi di messaggistica HTTP/1.1 e dalla gestione delle connessioni; il resto di RFC 7230 è reso obsoleto da "HTTP/1.1" [HTTP/1.1].

---