4. Priority Parameters (Prioritätsparameter)
Die Prioritätsinformationen sind eine Sequenz von Schlüssel-Wert-Paaren (Key-Value Pairs), die Raum für zukünftige Erweiterungen bieten. Jedes Schlüssel-Wert-Paar repräsentiert einen Prioritätsparameter (Priority Parameter).
Das Priority-HTTP-Header-Feld (Abschnitt 5) ist eine End-to-End-Methode zur Übertragung dieser Menge von Prioritätsparametern, wenn eine Anfrage oder eine Antwort ausgegeben wird. Nach dem Senden einer Anfrage kann ein Client seine Sicht auf die Antwortpriorität (Abschnitt 6) ändern, indem er HTTP-versionsspezifische PRIORITY_UPDATE-Frames sendet, wie in den Abschnitten 7.1 und 7.2 definiert. Frames übertragen Prioritätsparameter nur auf einem einzelnen Hop.
Vermittler (Intermediaries) können Prioritätssignale in einem PRIORITY_UPDATE-Frame oder Priority-Header-Feld konsumieren und produzieren. Ein Vermittler, der nur das Priority-Request-Header-Feld an den nächsten Hop weiterleitet, bewahrt das ursprüngliche End-to-End-Signal vom Client; siehe Abschnitt 14. Ein Vermittler könnte das Priority-Header-Feld weiterleiten und zusätzlich einen PRIORITY_UPDATE-Frame senden. Dies hätte den Effekt, das ursprüngliche Client-End-to-End-Signal beizubehalten, während der nächste Hop angewiesen wird, eine andere Priorität gemäß der Anleitung in Abschnitt 7 zu verwenden. Ein Vermittler, der ein Priority-Request-Header-Feld ersetzt oder hinzufügt, überschreibt das ursprüngliche Client-End-to-End-Signal, was die Priorisierung für alle nachfolgenden Empfänger der Anfrage beeinflussen kann.
Sowohl für das Priority-Header-Feld als auch für den PRIORITY_UPDATE-Frame wird die Menge der Prioritätsparameter als Dictionary (Wörterbuch) kodiert (siehe Abschnitt 3.2 von [STRUCTURED-FIELDS]).
Dieses Dokument definiert die Prioritätsparameter urgency (u) und incremental (i). Beim Empfang einer HTTP-Anfrage, die diese Prioritätsparameter nicht trägt, sollte (SHOULD) ein Server so handeln, als ob ihre Standardwerte angegeben wären.
Ein Vermittler kann Signale aus Anfragen und Antworten kombinieren, die er weiterleitet. Beachten Sie, dass das Weglassen von Prioritätsparametern in Antworten anders behandelt wird als das Weglassen in Anfragen; siehe Abschnitt 8.
Empfänger analysieren das Dictionary wie in Abschnitt 4.2 von [STRUCTURED-FIELDS] beschrieben. Wenn das Dictionary erfolgreich analysiert wird, stellt dieses Dokument die zusätzliche Anforderung, dass unbekannte Prioritätsparameter, Prioritätsparameter mit Werten außerhalb des Bereichs oder Werte unerwarteter Typen ignoriert werden müssen (MUST).
4.1. Urgency (Dringlichkeit)
Der Wert des urgency (u)-Parameters ist Integer (Ganzzahl) (siehe Abschnitt 3.3.1 von [STRUCTURED-FIELDS]), zwischen 0 und 7 einschließlich, in absteigender Reihenfolge der Priorität. Der Standardwert ist 3.
Endpunkte verwenden diesen Parameter, um ihre Sicht auf die Priorität von HTTP-Antworten zu kommunizieren. Der gewählte Wert der Dringlichkeit kann auf der Erwartung basieren, dass Server diese Information verwenden könnten, um HTTP-Antworten in der Reihenfolge ihrer Dringlichkeit zu übertragen. Je kleiner der Wert, desto höher die Priorität.
Das folgende Beispiel zeigt eine Anfrage für eine CSS-Datei mit der auf 0 gesetzten Dringlichkeit:
:method = GET
:scheme = https
:authority = example.net
:path = /style.css
priority = u=0
Ein Client, der ein Dokument abruft, das wahrscheinlich aus mehreren HTTP-Ressourcen besteht (z. B. HTML), sollte (SHOULD) der Hauptressource die Standard-Dringlichkeitsstufe zuweisen. Diese Konvention ermöglicht es Servern, die Dringlichkeit unter Verwendung von websitespezifischem Wissen zu verfeinern (siehe Abschnitt 8).
Die niedrigste Dringlichkeitsstufe (7) ist für Hintergrundaufgaben wie die Bereitstellung von Software-Updates reserviert. Diese Dringlichkeitsstufe sollte nicht (SHOULD NOT) zum Abrufen von Antworten verwendet werden, die einen Einfluss auf die Benutzerinteraktion haben.
4.2. Incremental (Inkrementell)
Der Wert des incremental (i)-Parameters ist Boolean (boolescher Wert) (siehe Abschnitt 3.3.6 von [STRUCTURED-FIELDS]). Er gibt an, ob eine HTTP-Antwort inkrementell verarbeitet werden kann, d. h. eine sinnvolle Ausgabe liefern kann, wenn Teile der Antwort eintreffen.
Der Standardwert des incremental-Parameters ist false (0).
Wenn ein Client gleichzeitige Anfragen mit dem auf false gesetzten incremental-Parameter stellt, gibt es keinen Vorteil darin, Antworten mit derselben Dringlichkeit gleichzeitig bereitzustellen, da der Client diese Antworten nicht inkrementell verarbeitet. Das nacheinander Bereitstellen nicht-inkrementeller Antworten mit derselben Dringlichkeit, in der Reihenfolge, in der diese Anfragen generiert wurden, wird als die beste Strategie angesehen.
Wenn ein Client gleichzeitige Anfragen mit dem auf true gesetzten incremental-Parameter stellt, kann das gleichzeitige Bereitstellen von Anfragen mit derselben Dringlichkeit vorteilhaft sein. Dies verteilt die Verbindungsbandbreite, was bedeutet, dass Antworten länger brauchen, um abgeschlossen zu werden. Inkrementelle Bereitstellung ist am nützlichsten, wenn mehrere Teilantworten den Clients einen gewissen Wert bieten können, bevor eine vollständige Antwort verfügbar ist.
Das folgende Beispiel zeigt eine Anfrage für eine JPEG-Datei mit dem auf 5 gesetzten urgency-Parameter und dem auf true gesetzten incremental-Parameter.
:method = GET
:scheme = https
:authority = example.net
:path = /image.jpg
priority = u=5, i
4.3. Defining New Priority Parameters (Definition neuer Prioritätsparameter)
Bei dem Versuch, neue Prioritätsparameter zu definieren, muss darauf geachtet werden, dass sie die von bestehenden Endpunkten oder Vermittlern durchgeführte Priorisierung, die die neu definierten Prioritätsparameter nicht verstehen, nicht nachteilig beeinträchtigen. Da unbekannte Prioritätsparameter ignoriert werden, sollten neue Prioritätsparameter die Interpretation der urgency (siehe Abschnitt 4.1) oder incremental (siehe Abschnitt 4.2) Prioritätsparameter nicht auf eine Weise ändern oder modifizieren, die nicht rückwärtskompatibel oder fallback-sicher ist.
Wenn es beispielsweise notwendig ist, mehr Granularität als acht Dringlichkeitsstufen bereitzustellen, wäre es möglich, den Bereich mit einem zusätzlichen Prioritätsparameter zu unterteilen. Implementierungen, die den Parameter nicht erkennen, können sicher weiterhin die weniger granularen acht Stufen verwenden.
Alternativ kann die Dringlichkeit erweitert werden. Beispielsweise könnte ein grafischer Benutzeragent einen visible-Prioritätsparameter senden, um anzugeben, ob sich die angeforderte Ressource innerhalb des Viewports befindet.
Generische Prioritätsparameter werden gegenüber herstellerspezifischen, anwendungsspezifischen oder bereitstellungsspezifischen Werten bevorzugt. Wenn in der Community kein generischer Wert vereinbart werden kann, sollte der Name des Parameters entsprechend spezifisch sein (z. B. mit einem Präfix, das den Hersteller, die Anwendung oder die Bereitstellung identifiziert).
4.3.1. Registration (Registrierung)
Neue Prioritätsparameter können definiert werden, indem sie im "HTTP Priority"-Register registriert werden. Dieses Register regelt die Schlüssel (kurze Textzeichenfolgen), die im Dictionary verwendet werden (siehe Abschnitt 3.2 von [STRUCTURED-FIELDS]). Da jede HTTP-Anfrage zugeordnete Prioritätssignale haben kann, ist es wertvoll, kurze Schlüssellängen zu haben, insbesondere Einzelzeichenfolgen. Um Erweiterungen zu fördern und gleichzeitig unbeabsichtigte Konflikte zwischen attraktiven Schlüsselwerten zu vermeiden, wendet das "HTTP Priority"-Register zwei Registrierungsrichtlinien an, abhängig von der Schlüssellänge.
-
Registrierungsanfragen für Prioritätsparameter mit einer Schlüssellänge von eins verwenden die Richtlinie Specification Required (Spezifikation erforderlich), gemäß Abschnitt 4.6 von [RFC8126].
-
Registrierungsanfragen für Prioritätsparameter mit einer Schlüssellänge größer als eins verwenden die Richtlinie Expert Review (Expertenüberprüfung), gemäß Abschnitt 4.5 von [RFC8126]. Ein Spezifikationsdokument wird geschätzt, ist aber nicht erforderlich.
Bei der Überprüfung von Registrierungsanfragen können die benannten Experten die in Abschnitt 4.3 bereitgestellten zusätzlichen Leitlinien berücksichtigen, können sie jedoch nicht als Grundlage für eine Ablehnung verwenden.
Registrierungsanfragen sollten die folgende Vorlage verwenden:
Name: [ein Name für den Prioritätsparameter, der dem Parameterschlüssel entspricht]
Description (Beschreibung): [eine Beschreibung der Semantik und des Werts des Prioritätsparameters]
Reference (Referenz): [auf eine Spezifikation, die diesen Prioritätsparameter definiert]
Details zum Senden von Registrierungsanfragen finden Sie im Register unter https://www.iana.org/assignments/http-priority.