2. Motivation for Replacing RFC 7540 Stream Priorities (Motivation für den Ersatz der RFC 7540 Stream-Prioritäten)
Die RFC 7540 Stream-Priorität (siehe Abschnitt 5.3 von [RFC7540]) ist ein komplexes System, bei dem Clients Stream-Abhängigkeiten und Gewichte signalisieren, um einen unausgeglichenen Baum zu beschreiben. Es litt unter begrenzter Bereitstellung und Interoperabilität und wurde in einer Überarbeitung von HTTP/2 [HTTP/2] als veraltet erklärt. HTTP/2 behält diese Protokollelemente bei, um die Leitungskompatibilität aufrechtzuerhalten (siehe Abschnitt 5.3.2 von [HTTP/2]), was bedeutet, dass sie möglicherweise auch bei Vorhandensein alternativer Signalisierung, wie dem in diesem Dokument beschriebenen Schema, noch verwendet werden könnten.
Viele RFC 7540-Serverimplementierungen reagieren nicht auf HTTP/2-Prioritätssignale.
Die Priorisierung kann Informationen verwenden, die Server über Ressourcen oder die Reihenfolge haben, in der Anfragen generiert werden. Beispielsweise könnte ein Server mit Kenntnis einer HTML-Dokumentstruktur die Bereitstellung von Bildern, die für die Benutzererfahrung kritisch sind, gegenüber anderen Bildern priorisieren wollen. Mit RFC 7540 ist es für Server schwierig, Signale von Clients zur Priorisierung zu interpretieren, da dieselben Bedingungen zu sehr unterschiedlicher Signalisierung von verschiedenen Clients führen könnten. Dieses Dokument beschreibt eine Signalisierung, die einfacher und eingeschränkter ist, weniger Interpretation erfordert und weniger Variation zulässt.
RFC 7540 definiert keine Methode, die von einem Server verwendet werden kann, um ein Prioritätssignal für Vermittler bereitzustellen.
Die RFC 7540 Stream-Priorität wird relativ zu anderen Anfragen ausgedrückt, die gleichzeitig dieselbe Verbindung teilen. Es ist schwierig, ein solches Design in Anwendungen zu integrieren, die Anfragen generieren, ohne zu wissen, wie andere Anfragen eine Verbindung teilen könnten, oder in Protokolle, die keine starken Ordnungsgarantien über Streams hinweg haben, wie HTTP/3 [HTTP/3].
Experimente aus unabhängiger Forschung [MARX] haben gezeigt, dass einfachere Schemata zumindest gleichwertige Leistungsmerkmale im Vergleich zu den komplexeren RFC 7540-Setups erreichen können, die in der Praxis beobachtet werden, zumindest für den Web-Anwendungsfall.
2.1. Disabling RFC 7540 Stream Priorities (Deaktivierung der RFC 7540 Stream-Prioritäten)
Die oben dargelegten Probleme und Erkenntnisse lieferten die Motivation für eine Alternative zur RFC 7540 Stream-Priorität (siehe Abschnitt 5.3 von [HTTP/2]).
Die HTTP/2-Einstellung SETTINGS_NO_RFC7540_PRIORITIES wird von diesem Dokument definiert, um Endpunkten zu ermöglichen, HTTP/2-Prioritätssignale wegzulassen oder zu ignorieren (siehe Abschnitt 5.3.2 von [HTTP/2]), wie unten beschrieben. Der Wert von SETTINGS_NO_RFC7540_PRIORITIES muss (MUST) 0 oder 1 sein. Jeder Wert außer 0 oder 1 muss (MUST) als Verbindungsfehler (siehe Abschnitt 5.4.1 von [HTTP/2]) vom Typ PROTOCOL_ERROR behandelt werden. Der Anfangswert ist 0.
Wenn Endpunkte SETTINGS_NO_RFC7540_PRIORITIES verwenden, müssen (MUST) sie es im ersten SETTINGS-Frame senden. Absender dürfen (MUST NOT) den SETTINGS_NO_RFC7540_PRIORITIES-Wert nach dem ersten SETTINGS-Frame nicht ändern. Empfänger, die eine Änderung erkennen, können (MAY) sie als Verbindungsfehler vom Typ PROTOCOL_ERROR behandeln.
Clients können SETTINGS_NO_RFC7540_PRIORITIES mit einem Wert von 1 senden, um anzuzeigen, dass sie keine HTTP/2-Prioritätssignale verwenden. Der SETTINGS-Frame geht allen HTTP/2-Prioritätssignalen voraus, die von Clients gesendet werden, sodass Server bestimmen können, ob sie Ressourcen für die Signalverarbeitung zuweisen müssen, bevor Signale eintreffen. Ein Server, der SETTINGS_NO_RFC7540_PRIORITIES mit einem Wert von 1 empfängt, muss (MUST) HTTP/2-Prioritätssignale ignorieren.
Server können SETTINGS_NO_RFC7540_PRIORITIES mit einem Wert von 1 senden, um anzuzeigen, dass sie HTTP/2-Prioritätssignale ignorieren werden, die von Clients gesendet werden.
Endpunkte, die SETTINGS_NO_RFC7540_PRIORITIES senden, werden ermutigt, alternative Prioritätssignale zu verwenden (siehe z. B. Abschnitt 5 oder Abschnitt 7.1), es gibt jedoch keine Anforderung, einen bestimmten Signaltyp zu verwenden.
2.1.1. Advice when Using Extensible Priorities as the Alternative (Ratschläge bei Verwendung erweiterbarer Prioritäten als Alternative)
Bevor ein Client einen SETTINGS-Frame von einem Server empfängt, weiß er nicht, ob der Server HTTP/2-Prioritätssignale ignoriert. Daher sollte (SHOULD) der Client, bis er den SETTINGS-Frame vom Server empfängt, sowohl die HTTP/2-Prioritätssignale als auch die Signale dieses Priorisierungsschemas senden (siehe Abschnitte 5 und 7.1).
Sobald der Client den ersten SETTINGS-Frame empfängt, der den Parameter SETTINGS_NO_RFC7540_PRIORITIES mit einem Wert von 1 enthält, sollte (SHOULD) er das Senden der HTTP/2-Prioritätssignale einstellen. Dies vermeidet das Senden redundanter Signale, von denen bekannt ist, dass sie ignoriert werden.
Wenn der Client SETTINGS_NO_RFC7540_PRIORITIES mit einem Wert von 0 empfängt oder wenn der Einstellungsparameter fehlt, sollte (SHOULD) er das Senden von PRIORITY_UPDATE-Frames (Abschnitt 7.1) einstellen, da diese Frames wahrscheinlich ignoriert werden. Der Client kann (MAY) jedoch weiterhin das Priority-Header-Feld (Abschnitt 5) senden, da es ein End-to-End-Signal ist, das für Knoten hinter dem Server nützlich sein könnte, mit dem der Client direkt verbunden ist.