4. Priority Parameters (Parametri di priorità)

Le informazioni sulla priorità sono una sequenza di coppie chiave-valore (Key-Value Pairs), che forniscono spazio per estensioni future. Ogni coppia chiave-valore rappresenta un parametro di priorità (Priority Parameter).

Il campo di intestazione HTTP Priority (Sezione 5) è un modo end-to-end per trasmettere questo insieme di parametri di priorità quando viene emessa una richiesta o una risposta. Dopo aver inviato una richiesta, un client può cambiare la propria visione della priorità della risposta (Sezione 6) inviando frame PRIORITY_UPDATE specifici della versione HTTP come definito nelle Sezioni 7.1 e 7.2. I frame trasmettono parametri di priorità solo su un singolo hop.

Gli intermediari (Intermediaries) possono consumare e produrre segnali di priorità in un frame PRIORITY_UPDATE o in un campo di intestazione Priority. Un intermediario che passa solo il campo di intestazione della richiesta Priority al prossimo hop preserva il segnale end-to-end originale dal client; vedere Sezione 14. Un intermediario potrebbe passare il campo di intestazione Priority e inoltre inviare un frame PRIORITY_UPDATE. Ciò avrebbe l'effetto di preservare il segnale end-to-end del client originale, istruendo al contempo il prossimo hop di utilizzare una priorità diversa, secondo le indicazioni della Sezione 7. Un intermediario che sostituisce o aggiunge un campo di intestazione della richiesta Priority sovrascrive il segnale end-to-end del client originale, il che può influenzare la prioritizzazione per tutti i destinatari successivi della richiesta.

Sia per il campo di intestazione Priority che per il frame PRIORITY_UPDATE, l'insieme dei parametri di priorità è codificato come Dictionary (dizionario) (vedere Sezione 3.2 di [STRUCTURED-FIELDS]).

Questo documento definisce i parametri di priorità urgency (u) e incremental (i). Quando si riceve una richiesta HTTP che non porta questi parametri di priorità, un server dovrebbe (SHOULD) agire come se fossero stati specificati i loro valori predefiniti.

Un intermediario può combinare segnali da richieste e risposte che inoltra. Si noti che l'omissione dei parametri di priorità nelle risposte è gestita in modo diverso dall'omissione nelle richieste; vedere Sezione 8.

I ricevitori analizzano il Dictionary come descritto nella Sezione 4.2 di [STRUCTURED-FIELDS]. Quando il Dictionary è analizzato con successo, questo documento pone il requisito aggiuntivo che i parametri di priorità sconosciuti, i parametri di priorità con valori fuori intervallo o valori di tipi imprevisti devono (MUST) essere ignorati.

4.1. Urgency (Urgenza)

Il valore del parametro urgency (u) è Integer (intero) (vedere Sezione 3.3.1 di [STRUCTURED-FIELDS]), tra 0 e 7 inclusi, in ordine decrescente di priorità. Il valore predefinito è 3.

Gli endpoint utilizzano questo parametro per comunicare la loro visione della precedenza delle risposte HTTP. Il valore scelto di urgenza può essere basato sull'aspettativa che i server potrebbero utilizzare queste informazioni per trasmettere risposte HTTP nell'ordine della loro urgenza. Più piccolo è il valore, maggiore è la precedenza.

Il seguente esempio mostra una richiesta per un file CSS con l'urgenza impostata a 0:

:method = GET
:scheme = https
:authority = example.net
:path = /style.css
priority = u=0

Un client che recupera un documento che probabilmente consiste di più risorse HTTP (ad es., HTML) dovrebbe (SHOULD) assegnare il livello di urgenza predefinito alla risorsa principale. Questa convenzione consente ai server di affinare l'urgenza utilizzando conoscenze specifiche del sito web (vedere Sezione 8).

Il livello di urgenza più basso (7) è riservato per attività in background come la consegna di aggiornamenti software. Questo livello di urgenza non dovrebbe (SHOULD NOT) essere utilizzato per recuperare risposte che hanno un impatto sull'interazione dell'utente.

4.2. Incremental (Incrementale)

Il valore del parametro incremental (i) è Boolean (booleano) (vedere Sezione 3.3.6 di [STRUCTURED-FIELDS]). Indica se una risposta HTTP può essere elaborata in modo incrementale, cioè fornire un output significativo man mano che arrivano i blocchi della risposta.

Il valore predefinito del parametro incremental è false (0).

Se un client effettua richieste concorrenti con il parametro incremental impostato su false, non c'è alcun beneficio nel servire risposte con la stessa urgenza in modo concorrente perché il client non elaborerà quelle risposte in modo incrementale. Servire risposte non incrementali con la stessa urgenza una alla volta, nell'ordine in cui sono state generate quelle richieste, è considerata la strategia migliore.

Se un client effettua richieste concorrenti con il parametro incremental impostato su true, servire richieste con la stessa urgenza in modo concorrente potrebbe essere vantaggioso. Ciò distribuisce la larghezza di banda della connessione, il che significa che le risposte impiegano più tempo per completarsi. La consegna incrementale è più utile quando più risposte parziali potrebbero fornire un certo valore ai client prima che sia disponibile una risposta completa.

Il seguente esempio mostra una richiesta per un file JPEG con il parametro urgency impostato a 5 e il parametro incremental impostato su true.

:method = GET
:scheme = https
:authority = example.net
:path = /image.jpg
priority = u=5, i

4.3. Defining New Priority Parameters (Definizione di nuovi parametri di priorità)

Quando si tenta di definire nuovi parametri di priorità, è necessario prestare attenzione affinché non interferiscano negativamente con la prioritizzazione eseguita da endpoint o intermediari esistenti che non comprendono i parametri di priorità appena definiti. Poiché i parametri di priorità sconosciuti vengono ignorati, i nuovi parametri di priorità non dovrebbero cambiare l'interpretazione o modificare i parametri di priorità urgency (vedere Sezione 4.1) o incremental (vedere Sezione 4.2) in un modo che non sia retrocompatibile o sicuro in caso di fallback.

Ad esempio, se c'è bisogno di fornire più granularità degli otto livelli di urgenza, sarebbe possibile suddividere l'intervallo utilizzando un parametro di priorità aggiuntivo. Le implementazioni che non riconoscono il parametro possono continuare in sicurezza a utilizzare gli otto livelli meno granulari.

In alternativa, l'urgenza può essere aumentata. Ad esempio, un user agent grafico potrebbe inviare un parametro di priorità visible per indicare se la risorsa richiesta si trova all'interno del viewport.

I parametri di priorità generici sono preferiti rispetto ai valori specifici del fornitore, dell'applicazione o del deployment. Se un valore generico non può essere concordato nella comunità, il nome del parametro dovrebbe essere corrispondentemente specifico (ad es., con un prefisso che identifica il fornitore, l'applicazione o il deployment).

4.3.1. Registration (Registrazione)

Nuovi parametri di priorità possono essere definiti registrandoli nel registro "HTTP Priority". Questo registro governa le chiavi (brevi stringhe testuali) utilizzate nel Dictionary (vedere Sezione 3.2 di [STRUCTURED-FIELDS]). Poiché ogni richiesta HTTP può avere segnali di priorità associati, c'è valore nell'avere lunghezze di chiave brevi, specialmente stringhe di un singolo carattere. Per incoraggiare le estensioni evitando al contempo conflitti non intenzionali tra valori di chiave attraenti, il registro "HTTP Priority" opera due politiche di registrazione, a seconda della lunghezza della chiave.

• Le richieste di registrazione per parametri di priorità con una lunghezza della chiave di uno utilizzano la politica Specification Required (specifica richiesta), secondo la Sezione 4.6 di [RFC8126].

• Le richieste di registrazione per parametri di priorità con una lunghezza della chiave maggiore di uno utilizzano la politica Expert Review (revisione esperta), secondo la Sezione 4.5 di [RFC8126]. Un documento di specifica è apprezzato ma non richiesto.

Quando si esaminano le richieste di registrazione, l'esperto o gli esperti designati possono considerare le indicazioni aggiuntive fornite nella Sezione 4.3 ma non possono utilizzarle come base per il rifiuto.

Le richieste di registrazione dovrebbero utilizzare il seguente modello:

Name (Nome): [un nome per il parametro di priorità che corrisponde alla chiave del parametro]

Description (Descrizione): [una descrizione della semantica e del valore del parametro di priorità]

Reference (Riferimento): [a una specifica che definisce questo parametro di priorità]

Vedere il registro all'indirizzo https://www.iana.org/assignments/http-priority per dettagli su dove inviare le richieste di registrazione.

---