Zusammenfassung

  • RFC 7540 gab HTTP/2-Servern die Möglichkeit, wahrscheinliche Folgedateien mit PUSH_PROMISE anzukündigen und vor der nächsten Browseranfrage zu senden. Der Client konnte dies abschalten oder zurückweisen.
  • RFC 9113 behielt Server Push 2022 bei und beschrieb die Kosten falscher Vorhersagen. Die Mitteilung zu Chrome 106 dokumentierte danach die Entfernung des Empfangs, der Speicherung und der Nutzung solcher Ströme.

Der Server formuliert die nächste Anfrage selbst

Eine HTML-Seite verweist auf ein Stylesheet. Der Server kennt diesen Verweis, bevor der Browser die Seite gelesen hat. Wenn er die Datei schon losschickt, könnte ein weiterer Weg zwischen Client und Server entfallen. Die HTTP/2-Spezifikation von 2015 beschrieb dafür PUSH_PROMISE: Der Server kündigt eine von ihm vermutete Anfrage an und liefert die Antwort auf einem eigenen Datenstrom.

Auch diese Initiative hatte Grenzen. Der Push musste mit einer wirklichen Anfrage des Clients zusammenhängen, eine sichere und cachefähige Ressource betreffen und die Zuständigkeit der Quelle respektieren. Ein Browser konnte SETTINGS_ENABLE_PUSH=0 setzen oder einen unerwünschten Strom abbrechen. Der Standard gab dem Server ein Recht zum Vorschlagen, aber kein Wissen darüber, was der Client tatsächlich benötigte.

Der Browser kann eine Datei längst im Cache haben. Eine andere Sprach- oder Inhaltsvariante kann erforderlich sein. Der Nutzer kann die Seite verlassen. Dann beansprucht eine vorab gesendete Antwort Übertragungskapazität, obwohl eine angeforderte Antwort dringender wäre. Die Optimierung spart nur Zeit, wenn die Vorhersage stimmt und zur richtigen Reihenfolge passt.

Die neue Norm beschreibt die alte Wette

Der RFC 9113 vom Juni 2022 enthielt weiterhin einen vollständigen Abschnitt über Server Push. Er erklärte das mögliche Plus: Ein passend vorab geliefertes Skript oder Stylesheet erspart dem Browser eine weitere Anfragerunde. Direkt daneben stand die praktische Schwierigkeit. Der Server müsste Cachezustand, Inhaltsaushandlung und Nutzerverhalten richtig antizipieren. Ein Fehlgriff kann wichtigere Antworten verdrängen und die Leistung verschlechtern.

Die Revision behielt auch den Schalter bei, mit dem Clients Push deaktivieren konnten. Das Dokument regelte also eine erlaubte Kommunikation samt Ausstieg. Ob ein Browserteam den Empfang, die Speicherverwaltung und die Abstimmung mit dem Cache weiter betreibt, ist eine andere Entscheidung. Eine Funktion im RFC bedeutet noch keine Funktion im nächsten Browserrelease.

Chrome kündigte im August 2022 an, HTTP/2 Server Push in Version 106 standardmäßig abzuschalten. Die Produktbegründung nannte schwer erreichbare Leistungsvorteile und gemischte Ergebnisse bis hin zu Rückschritten. Die Chrome-106-Änderungsliste bezeichnete den ausgeführten Schritt genauer: Empfang, Zwischenspeicherung im Arbeitsspeicher und Verwendung gepushter Ströme wurden entfernt. Der RFC behielt die Regeln; Chrome legte die Arbeit auf seiner Seite nieder.

Die zeitliche Nähe macht den Fall besonders klar. Im Juni erschien eine Norm, die das Problem ausdrücklich benannte und den Mechanismus trotzdem behielt. Wenige Monate später endete die Unterstützung in einem Browser. Die Norm war kein Irrtum im Sinne einer undefinierten Funktion. Ihre Implementation hatte sich als unattraktive Daueraufgabe erwiesen.

Ein Hinweis statt einer ganzen Datei

Als Alternativen führte Chrome 103 Early Hints und Preload an. Early Hints verrät dem Browser früh eine mögliche Ressource; er entscheidet selbst, ob er sie anfordert, etwa nach Blick auf seinen Cache. Das ist der wesentliche Unterschied für diese Geschichte: Bei Server Push war die komplette Antwort bereits unterwegs, weil der Server den nächsten Wunsch zu kennen glaubte.

HTTP/2 wurde nicht abgeschafft. Server Push blieb in der Spezifikation. Chrome 106 stellte den Empfang ein. In dieser Dreiteilung liegt die Geschichte einer Protokolloption, die auf dem Papier weiterlebt, nachdem ein Stück des laufenden Webs sie nicht mehr nutzt.