1. Introduction (Introduzione)
È comune che le rappresentazioni (Representations) di una risorsa HTTP [HTTP] abbiano relazioni con una o più altre risorse. I client spesso scoprono queste relazioni durante l'elaborazione di una rappresentazione recuperata, il che può portare a ulteriori richieste di recupero. Nel frattempo, la natura delle relazioni determina se un client è bloccato dal continuare a elaborare le risorse disponibili localmente. Un esempio di ciò è il rendering visivo di un documento HTML, che potrebbe essere bloccato dal recupero di un file Cascading Style Sheets (CSS) a cui il documento fa riferimento. Al contrario, le immagini inline non bloccano il rendering e vengono disegnate in modo incrementale man mano che arrivano i blocchi delle immagini.
HTTP/2 [HTTP/2] e HTTP/3 [HTTP/3] supportano il multiplexing di richieste e risposte in una singola connessione. Una caratteristica importante di qualsiasi implementazione di un protocollo che fornisce il multiplexing è la capacità di dare priorità all'invio di informazioni. Ad esempio, per fornire una presentazione significativa di un documento HTML nel momento più precoce possibile, è importante per un server HTTP dare priorità alle risposte HTTP, o ai blocchi di tali risposte HTTP, che invia a un client.
I server HTTP/2 e HTTP/3 possono pianificare la trasmissione di dati di risposta concorrenti con qualsiasi mezzo scelgano. I server possono ignorare i segnali di priorità (Priority Signals) del client e comunque servire con successo le risposte HTTP. Tuttavia, i server che operano senza conoscere come i client emettono richieste e consumano risposte possono causare prestazioni dell'applicazione client non ottimali. I segnali di priorità consentono ai client di comunicare la loro visione della priorità delle richieste. I server hanno le proprie esigenze indipendenti dalle esigenze dei client, quindi spesso combinano i segnali di priorità con altre informazioni disponibili al fine di informare la pianificazione dei dati di risposta.
La priorità di stream (Stream Priority) RFC 7540 [RFC7540] permetteva a un client di inviare una serie di segnali di priorità che comunicano al server un "albero di priorità (Priority Tree)"; la struttura di questo albero rappresenta l'ordinamento relativo preferito del client e la distribuzione ponderata della larghezza di banda tra le risposte HTTP. I server potevano utilizzare questi segnali di priorità come input nelle decisioni di prioritizzazione.
Il design e l'implementazione della priorità di stream RFC 7540 sono stati osservati avere carenze, come spiegato nella Sezione 2. HTTP/2 [HTTP/2] ha di conseguenza deprecato l'uso di questi segnali di priorità di stream. Lo schema di prioritizzazione e i segnali di priorità definiti in questo documento possono fungere da sostituto per la priorità di stream RFC 7540.
Questo documento descrive uno schema estensibile per prioritizzare le risposte HTTP che utilizza valori assoluti. La Sezione 4 definisce i parametri di priorità (Priority Parameters), che sono un formato standardizzato ed estensibile di informazioni sulla priorità. La Sezione 5 definisce il campo di intestazione HTTP Priority (Priority HTTP Header Field), che è un segnale di priorità end-to-end indipendente dalla versione del protocollo. I client possono inviare questo campo di intestazione per segnalare la loro visione di come le risposte dovrebbero essere prioritizzate. Allo stesso modo, i server dietro un intermediario possono utilizzarlo per segnalare la priorità all'intermediario. Dopo aver inviato una richiesta, un client può cambiare la propria visione della priorità della risposta (vedere Sezione 6) inviando frame specifici della versione HTTP come definito nelle Sezioni 7.1 e 7.2.
I segnali di priorità del campo di intestazione e del frame sono input per il processo di prioritizzazione delle risposte di un server. Sono solo un suggerimento e non garantiscono alcun ordine particolare di elaborazione o trasmissione per una risposta rispetto a qualsiasi altra risposta. Le Sezioni 10 e 12 forniscono considerazioni e indicazioni su come i server potrebbero agire sui segnali.
1.1. Notational Conventions (Convenzioni notazionali)
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.
Questo documento utilizza la seguente terminologia dalla Sezione 3 di [STRUCTURED-FIELDS] per specificare sintassi e analisi: "Boolean" (booleano), "Dictionary" (dizionario) e "Integer" (intero).
Le richieste e le risposte HTTP di esempio utilizzano la formattazione in stile HTTP/2 da [HTTP/2].
Questo documento utilizza la codifica di interi a lunghezza variabile (Variable-Length Integer Encoding) da [QUIC].
Il termine "control stream" (flusso di controllo) è utilizzato per descrivere sia il flusso HTTP/2 con identificatore 0x0 che il flusso di controllo HTTP/3; vedere Sezione 6.2.1 di [HTTP/3].
Il termine "HTTP/2 priority signal" (segnale di priorità HTTP/2) è utilizzato per descrivere le informazioni di priorità inviate dai client ai server nei frame HTTP/2; vedere Sezione 5.3.2 di [HTTP/2].