1. Introduction (Einführung)
Es ist üblich, dass Darstellungen (Representations) einer HTTP [HTTP]-Ressource Beziehungen zu einer oder mehreren anderen Ressourcen haben. Clients entdecken diese Beziehungen häufig bei der Verarbeitung einer abgerufenen Darstellung, was zu weiteren Abrufanfragen führen kann. Gleichzeitig bestimmt die Art der Beziehungen, ob ein Client daran gehindert wird, die Verarbeitung lokal verfügbarer Ressourcen fortzusetzen. Ein Beispiel hierfür ist das visuelle Rendering eines HTML-Dokuments, das durch das Abrufen einer Cascading Style Sheets (CSS)-Datei blockiert werden könnte, auf die das Dokument verweist. Im Gegensatz dazu blockieren Inline-Bilder das Rendering nicht und werden schrittweise gezeichnet, wenn die Bildabschnitte eintreffen.
HTTP/2 [HTTP/2] und HTTP/3 [HTTP/3] unterstützen das Multiplexing von Anfragen und Antworten in einer einzigen Verbindung. Ein wichtiges Merkmal jeder Implementierung eines Protokolls, das Multiplexing bereitstellt, ist die Fähigkeit, das Senden von Informationen zu priorisieren. Um beispielsweise eine sinnvolle Darstellung eines HTML-Dokuments zum frühestmöglichen Zeitpunkt bereitzustellen, ist es für einen HTTP-Server wichtig, die HTTP-Antworten oder die Abschnitte dieser HTTP-Antworten, die er an einen Client sendet, zu priorisieren.
HTTP/2- und HTTP/3-Server können die Übertragung gleichzeitiger Antwortdaten auf jede von ihnen gewählte Weise planen. Server können Client-Prioritätssignale (Priority Signals) ignorieren und dennoch erfolgreich HTTP-Antworten bereitstellen. Server, die jedoch ohne Kenntnis darüber arbeiten, wie Clients Anfragen stellen und Antworten konsumieren, können eine suboptimale Client-Anwendungsleistung verursachen. Prioritätssignale ermöglichen es Clients, ihre Sicht auf die Anforderungspriorität zu kommunizieren. Server haben ihre eigenen Bedürfnisse, die unabhängig von den Client-Bedürfnissen sind, daher kombinieren sie Prioritätssignale häufig mit anderen verfügbaren Informationen, um die Planung von Antwortdaten zu informieren.
Die RFC 7540 [RFC7540] Stream-Priorität (Stream Priority) erlaubte es einem Client, eine Reihe von Prioritätssignalen zu senden, die dem Server einen „Prioritätsbaum (Priority Tree)" mitteilen; die Struktur dieses Baums stellt die bevorzugte relative Reihenfolge und gewichtete Verteilung der Bandbreite unter HTTP-Antworten des Clients dar. Server konnten diese Prioritätssignale als Eingabe für Priorisierungsentscheidungen verwenden.
Das Design und die Implementierung der RFC 7540 Stream-Priorität wiesen Mängel auf, wie in Abschnitt 2 erläutert. HTTP/2 [HTTP/2] hat daher die Verwendung dieser Stream-Prioritätssignale als veraltet erklärt. Das in diesem Dokument definierte Priorisierungsschema und die Prioritätssignale können als Ersatz für die RFC 7540 Stream-Priorität dienen.
Dieses Dokument beschreibt ein erweiterbares Schema zur Priorisierung von HTTP-Antworten, das absolute Werte verwendet. Abschnitt 4 definiert Prioritätsparameter (Priority Parameters), die ein standardisiertes und erweiterbares Format von Prioritätsinformationen darstellen. Abschnitt 5 definiert das Priority-HTTP-Header-Feld (Priority HTTP Header Field), das ein versionsunabhängiges End-to-End-Prioritätssignal ist. Clients können dieses Header-Feld senden, um ihre Sicht darauf zu signalisieren, wie Antworten priorisiert werden sollten. Ebenso können Server hinter einem Vermittler es verwenden, um dem Vermittler die Priorität zu signalisieren. Nach dem Senden einer Anfrage kann ein Client seine Sicht auf die Antwortpriorität ändern (siehe Abschnitt 6), indem er HTTP-versionsspezifische Frames sendet, wie in den Abschnitten 7.1 und 7.2 definiert.
Header-Feld- und Frame-Prioritätssignale sind Eingaben für den Antwortpriorisierungsprozess eines Servers. Sie sind nur ein Vorschlag und garantieren keine bestimmte Verarbeitungs- oder Übertragungsreihenfolge für eine Antwort im Verhältnis zu einer anderen Antwort. Die Abschnitte 10 und 12 bieten Überlegungen und Anleitungen darüber, wie Server auf Signale reagieren könnten.
1.1. Notational Conventions (Notationskonventionen)
Die Schlüsselwörter „MUST", „MUST NOT", „REQUIRED", „SHALL", „SHALL NOT", „SHOULD", „SHOULD NOT", „RECOMMENDED", „NOT RECOMMENDED", „MAY" und „OPTIONAL" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.
Dieses Dokument verwendet die folgende Terminologie aus Abschnitt 3 von [STRUCTURED-FIELDS] zur Spezifikation von Syntax und Parsing: „Boolean" (Boolescher Wert), „Dictionary" (Wörterbuch) und „Integer" (Ganzzahl).
Beispiel-HTTP-Anfragen und -Antworten verwenden die HTTP/2-Formatierung aus [HTTP/2].
Dieses Dokument verwendet die Kodierung variabler Länge für Ganzzahlen (Variable-Length Integer Encoding) aus [QUIC].
Der Begriff „control stream" (Kontrollstrom) wird verwendet, um sowohl den HTTP/2-Stream mit der Kennung 0x0 als auch den HTTP/3-Kontrollstrom zu beschreiben; siehe Abschnitt 6.2.1 von [HTTP/3].
Der Begriff „HTTP/2 priority signal" (HTTP/2-Prioritätssignal) wird verwendet, um die Prioritätsinformationen zu beschreiben, die von Clients an Server in HTTP/2-Frames gesendet werden; siehe Abschnitt 5.3.2 von [HTTP/2].