Firefox beabsichtigt, Unterstützung für HTTP/2 Push einzustellen

 (groups.google.com)
1 Punkte von GN⁺ 2024-09-08 | 1 Kommentare | Auf WhatsApp teilen
  • Firefox wird HTTP/2 Push wegen geringer Nutzung und zunehmender Kompatibilitätslast in den nächsten Tagen auf allen Plattformen deaktivieren; der Implementierungscode soll vorerst im Tree verbleiben
  • Im Browser-Ökosystem ist die Unterstützung bereits zurückgegangen; Chrome 106 hat sie im September 2022 abgeschaltet, und auch die aktuelle Safari-Version lehnt in lokalen Tests Push-Streams ab
  • Chrome verwies auf die geringe Nutzung von HTTP/2 Push und empfahl als Alternativen rel="preload" und 103 Early Hints
  • Firefox hatte die Unterstützung beibehalten, weil der Wartungsaufwand nicht groß war, doch in den vergangenen Monaten traten wegen HTTP/2 Push Webkompatibilitätsfehler auf, die nur in Firefox auftreten
  • Wenn Server und Websites Push nutzen, aber Tests mit Firefox auslassen, können bestimmte Websites nur in Firefox nicht funktionieren

Firefoxs Plan zur Deaktivierung von HTTP/2 Push

  • Firefox wird HTTP/2 Push auf allen Plattformen deaktivieren
  • Die Entfernung wird in Bugzilla unter 1915848 - Pref off HTTP/2 push verfolgt
  • Vorerst wird es per Preference abgeschaltet, der Implementierungscode bleibt zunächst im Tree
  • Die vollständige Entfernung wird voraussichtlich vor dem ESR-140-Branch im kommenden Frühjahr erfolgen

Unterstützungsstatus nach Browser und Gründe für die Deaktivierung

  • Chrome

    • Chrome 106 hat HTTP/2 Push im September 2022 deaktiviert
    • Der zugehörige Status ist unter Chrome Platform Status einsehbar
    • Chrome nannte die geringe Nutzung als Grund und empfahl rel="preload" sowie 103 Early Hints als Alternativen

  • Safari

    • Offizielle Deprecation-Unterlagen konnten nicht gefunden werden, aber die aktuelle Version lehnt in lokalen Tests mit einem Node.js-Server Push-Streams ab

  • Firefox

    • Firefox hat die Unterstützung für HTTP/2 Push bislang fortgeführt, weil der Wartungsaufwand nicht groß war
    • In den vergangenen Monaten sind durch HTTP/2 Push Webkompatibilitätsprobleme entstanden, die nur Firefox betreffen
      • Ein zugehöriges Beispiel ist bug 1915830
      • Wenn Server und Websites Push verwenden, aber nicht in Firefox testen, kann eine Website nur in Firefox hängen bleiben; ein Beispiel dafür ist bug 1913100

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-08
Hacker-News-Kommentare

  • Es ist frustrierend, dass es keinerlei Entschuldigung für diejenigen gibt, die schon lange erklärt hatten, warum HTTP/2 Push nicht funktionieren würde, und damals ignoriert wurden, selbst nachdem plötzlich die „Erkenntnis“ auftauchte, dass es am Ende doch nicht klappt
    Jahrelang herrschte die Stimmung, man solle es einfach in die Spezifikation drücken, weil Googles klügere Leute es angeblich bräuchten, dabei sollte man an Spezifikationen viel vorsichtiger herangehen. Man sollte aufhören, ständig spekulative Erweiterungsziele hineinzupacken, nur weil Teile von Google sie für gut halten

    • HTTP und Web-Performance zu verbessern wirkt ohnehin nicht besonders sinnvoll. Es gibt schon genug Bandbreite für 1080p-Videostreaming, die Latenz ist niedrig genug für Echtzeitspiele, und die CPU ist 1000-mal leistungsfähiger als bei der ersten Einwahl ins Netz
      Was Browser langsam macht, sind meist nur Werbung, Tracker und sonstiger Ballast, die Websites erdrücken, und was das behebt, ist keine Google-Erfindung, sondern uBlock Origin. Was Google heute in Webstandards drückt, scheint nicht für normale Entwickler zu sein, sondern eher dafür, mehr Werbung unterzubringen oder 0,1 % an Rechenzentrumskosten zu sparen
    • Wenn man schon lange sagt, dass für nichtgrafische Webnutzung, etwa schnelle und nichtinteraktive Informationsabfragen, HTTP/1.1-Pipelining befriedigender war als HTTP/2, bekam man auf HN oft Downvotes und spöttische Antworten
      HTTP/2 wirkt wie ein Fall, in dem ein einzelnes Unternehmen den Zugang zur öffentlichen Ressource WWW weiter im eigenen Interesse kontrollieren will. Wer Chrome benutzt, versucht dann HTTP/2, und dieselbe Firma kontrolliert Suchmaschine, Hardware, Browser und jetzt sogar Netzwerkprotokolle. HTTP/2 ist praktisch HTTP/Chrome
    • Man sollte Verständnis dafür haben, dass diese Leute ihre jährlichen Beförderungsunterlagen wirklich brauchten
    • Wer zu früh recht hat, liegt genauso falsch

  • Die Erklärungen dafür, warum HTTP/2 Push gescheitert sei, haben auf mich nie überzeugend gewirkt. Google verweist meist auf einen Artikel von Jake Archibald, aber der liest sich eher wie eine Aufzählung, wie mangelhaft die Browser-Implementierung war, als wie eine Begründung dafür, dass das Protokoll selbst nicht funktionieren könne
    Browser unterstützen bereits Preload-Links, und diese sollten im Wesentlichen dieselbe Rolle wie Push-Header erfüllen. Auch bei Problemen der Implementierungen von 2017 wie Caching oder Authentifizierungs-Headern frage ich mich, warum sich bestehender Code zur Verarbeitung von Preload nicht wiederverwenden ließ
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • Preload-Header kann man nicht als „im Wesentlichen gleich“ mit HTTP/2 Push ansehen. Die Ergebnisse können ähnlich sein, aber die Funktionsweise ist anders, und abgesehen vom sehr oberflächlichen Punkt, dass das Wort „Preload“ vorkommt, unterscheiden sie sich deutlich
      Bei HTTP/2 Push schiebt der Server Ressourcen proaktiv zum Client, die dieser seiner Einschätzung nach brauchen wird, um einen Roundtrip zu sparen. Ziel ist, Latenz zu senken, indem Ressourcen unabhängig von der DOM→Render-Pipeline gesendet werden. Beim Preload-Header teilt der Server mit dem Response-Body mit, welche Ressourcen parallel geladen werden sollen, damit sie vor dem Parsen oder der Auswertung von JS geholt werden. 103 Early Hints senden Preload-Hinweise noch bevor die Response-Erzeugung abgeschlossen ist, also noch vor dem ersten Byte des Bodys, und ziehen den Fetch-Schritt damit weiter nach vorn
      Der Kernunterschied ist servergesteuert versus clientgesteuert sowie mit dem Body versus vor dem ersten Byte. Der einfachste Grund, warum HTTP/2 Push sein Ziel schlecht erreicht, ist der Cache. Der Browser fordert Ressourcen, die er schon hat, gar nicht erst an, aber der Server weiß nicht, was im Client-Cache liegt. Bei Push ist das Risiko groß, unnötige Ressourcen zu senden, während bei 103/Preload im Fehlerfall nur ein paar nutzlose Header-Bytes verschwendet werden, was die Implementierung einfacher und die Kosten geringer macht
    • Mein Verständnis der Push-Spezifikation war fast so eingerostet wie die Spezifikation selbst. Ich hatte vergessen, dass der Server tatsächlich den gesamten Inhalt pusht, den der Client seiner Einschätzung nach brauchen wird, und irrtümlich angenommen, die Requests enthielten nur Header, die wie Preload-Links Abhängigkeiten andeuten
    • Aus Sicherheitsgründen müssen gepushte Ressourcen bis zur Übernahme durch die Seite als Sonderfall behandelt werden, und dazu gehört unter anderem ein separater Cache
    • Die Ausrede für das Entfernen von Push ist besonders lächerlich, weil Entwickler fast nie die Chance hatten, Push überhaupt richtig zu nutzen. Man konnte eingehenden Push weder sehen noch darauf reagieren
      https://github.com/whatwg/fetch/issues/51
      Selbst beim Anwendungsfall der Auslieferung von Inhalten, auf den sich alle konzentrierten, scheint es noch viele Möglichkeiten gegeben zu haben. Es gab auch nicht viele öffentlich sichtbare Versuche, und kaum jemand hatte Zugang zu Bibliotheken oder Ausgangspunkten, um zu experimentieren, was man überhaupt pushen sollte

  • Mit HTTP/3 0-RTT-Start lässt sich ein Teil der Geschwindigkeit zurückholen, und mit 103 Early Hints kann man den Browser Assets früh preloaden lassen. Diese Kombination hat zudem den Vorteil, semantisch abwärtskompatibel zu HTTP/1 zu sein. Auch in Reverse Proxies oder Load Balancern ist sie leichter zu handhaben

  • Es ist etwas schade zu sehen, dass HTTP/2 Push nun doch verschwindet. Die Idee war elegant, aber die Unterstützung in Frameworks blieb schwach, und es ist eine Funktion, die mehr Aufmerksamkeit verdient hätte
    .NET hat es am Ende nie ausgeliefert, und nginx hatte eine Art Basisimplementierung. Auch das Fehlen von Cache Digests hat es immer wieder ausgebremst. Chrome entfernte es teils mit der Begründung, „es wird sowieso niemand bemerken“, und offenbar war es wichtiger, alles mit UDP neu zu entwerfen, das hinter NAT bekanntlich immer hervorragend funktioniert

    • Ich hatte noch nie Probleme mit UDP und NAT, aber wenn das die Leute genug nervt, um die Migration zu IPv6 voranzutreiben, würde ich still in mich hinein grinsen

  • Schon bevor HTTP/2 standardisiert wurde, war bei Gesprächen mit Mike Belshe die Stimmung da, diese Funktion eher aus H2 herauszunehmen, weil es bereits schwer war, den Nutzen zu realisieren, und es viele Probleme und Fallstricke gab
    Eines der größten Probleme war übermäßiger Push: Es wurde etwas gesendet, das schon im Browser-Cache lag, oder es wurde zu viel unwichtiger Inhalt geschickt. Ich habe tatsächlich sehr schlechte Fälle gesehen, in denen Push das Laden der Seite noch langsamer gemacht hat. Es gab auch Vorschläge, dass der Browser dem Server mitteilt, was sich im lokalen Cache befindet, aber die stießen auf verschiedene Probleme. HTTP Early Hints und Resource Hints haben den Bedarf an H2 Push weitgehend ersetzt, sind viel einfacher zu implementieren, vermeiden unnötige Fetches und sind auch leichter zu verstehen

  • Man kann das auch so lesen: „Wenn Webserver und Websites Push verwenden und nicht mit Firefox testen, kann die Website nur in Firefox hängen bleiben“ — aber es ist auch eine andere Deutung möglich.
    Andere Browser lehnen HTTP/2 Push ab und ignorieren es stillschweigend, während Firefox unter einigen Randbedingungen heftig stolpert. Zum Beispiel heißt es, „Firefox setzt die Verbindung offenbar zurück, wenn ein Header-Name Großbuchstaben enthält“.

    • Diese Deutung passt nicht gut. Die anderen Browser haben die Spezifikation nicht implementiert, und Firefox implementiert die Spezifikation. Die Spezifikation ist sehr eindeutig darin, wie mit diesem Verstoß umzugehen ist, und genau diese Webserver- und Website-Implementierungen sind kaputt. Hätte man mit einem spezifikationskonformen Client getestet, wäre aufgefallen, dass es kaputt ist.
    • Im Text wird das klar gesagt. Firefox hat die Unterstützung für HTTP/2 Push weitergeführt, weil die Kosten dafür bis vor Kurzem nicht hoch waren, aber in den letzten Monaten sind über HTTP/2 Push Webkompatibilitäts-Bugs aufgetreten, die nur Firefox betreffen.
      Dieser Text scheint genau die Maßnahme zu beschreiben, HTTP/2 Push wie andere Browser abzulehnen und stillschweigend zu ignorieren; es wirkt nicht so, als würde hier etwas verheimlicht.
    • Genauso gut hätte es auch umgekehrt passieren können. Eine neue Spezifikation wird nur in einem Browser implementiert, oft liefert Chrome zuerst eine unvollständige Umsetzung aus, und Server implementieren sie fehlerhaft, sodass dasselbe Problem entsteht.

  • Ich frage mich, warum Push nicht breiter angenommen wurde. Trotz seiner großen Mängel war es einer der Hauptgründe, warum HTTP/2 als potenziell bahnbrechendes Feature galt.
    Ich weiß nicht, ob es an mangelnder Browser-Unterstützung lag oder daran, dass es nicht gut zu CDNs passte.

    • Der Grund, warum Server Push nicht in großem Maßstab ausgerollt wurde, ist, dass es schädlich sein kann. Der Server schiebt Assets an den Client, die dieser vielleicht braucht, die aber möglicherweise bereits im Cache des Clients liegen.
      Im zweiten Fall ist das unnötige Last und besonders auf Mobilgeräten schädlich. Der Server kann niemals genau wissen, ob der Client dieses Asset tatsächlich braucht. Early Hints sind wahrscheinlich besser: Der Server kann die benötigten Assets früh ankündigen, und der Client kann selbst entscheiden, ob er sie holen muss oder bereits hat.
    • Ich hatte die Nutzung in Betracht gezogen, dann aber meine Meinung geändert. Wenn eine Anfrage für index.html hereinkommt, möchte man normalerweise script.js und style.css mitschieben, und damit hätte man bereits einige hundert kbit gesendet.
      Wenn der Nutzer index.html erneut anfordert, soll man dann alles noch einmal senden? Wahrscheinlich befinden sich die Ressourcen schon im Cache des Nutzers. Wenn man sie nicht sendet, woher soll man wissen, was stattdessen gesendet werden muss? Was im Cache vorhanden ist und was nicht, weiß nur der Browser. Am Ende steht man vor der Wahl, den ersten Besuch zu beschleunigen und bei Wiederholungsbesuchen Bandbreite zu verschwenden, oder den ersten Besuch langsamer zu lassen und Wiederholungsbesuche zu beschleunigen.
    • Es hätte durchaus ein bahnbrechendes Feature sein können, aber das galt für Unternehmen in der Größenordnung von Google/Amazon/Meta oder etwas kleiner.
      Für die meisten anderen war es ein massiver Anstieg der Komplexität und wurde faktisch ignoriert.
    • Der ausführlichere Analysebeitrag, den Chrome bei der Entscheidung zur Einstellung der Push-Unterstützung veröffentlicht hat, könnte hilfreich sein.
      https://developer.chrome.com/blog/removing-push/
    • Es wirkt, als wäre nicht genug Zeit gegeben worden. Erst 2015, als das HTTP/2-RFC abgeschlossen wurde, erschien die erste Apache-Version mit HTTP/2-Unterstützung, und selbst 2017 gab es noch Unterschiede zwischen Browsern bei der Behandlung von Server Push.
      Die Push-Unterstützung von nginx scheint laut Wikipedia ungefähr 2018 hinzugekommen zu sein. Solche Änderungen brauchen Zeit, bis sie in Versionen mit stabilem Release und in die Standardkonfigurationen einsickern. Auf meinem Apache-Server habe ich HTTP/2 sogar erst 2020 erstmals aktiviert, und selbst 2024 gibt es wahrscheinlich noch Application-Server, die es nicht direkt unterstützen.

  • … in Firefox.

    • Scheint andernorts bereits überall entfernt worden zu sein.

  • Scheint ein verwandter Beitrag zu sein. Gibt es noch mehr?
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - August 2022, 201 Kommentare
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - Juli 2022, 2 Kommentare
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - Dezember 2020, 168 Kommentare
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - November 2020, 133 Kommentare
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - September 2020, 2 Kommentare
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - Januar 2020, 71 Kommentare
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - Oktober 2018, 16 Kommentare
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - Februar 2018, 63 Kommentare
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - Juli 2017, 23 Kommentare
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - Mai 2017, 20 Kommentare
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - April 2017, 59 Kommentare
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - März 2017, 2 Kommentare
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - Februar 2017, 9 Kommentare
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - August 2016, 6 Kommentare
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - August 2016, 25 Kommentare
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - August 2016, 2 Kommentare
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - Februar 2016, 13 Kommentare

  • Nicht überraschend. Wenn man auf ein bestehendes Protokoll, das für einen bestimmten Zweck entwickelt wurde, eine Funktion draufsetzt, die mit dem ursprünglichen Designziel fast nichts zu tun hat, endet es meist so.
    In den meisten Fällen ist es besser, mit einem Low-Level-Protokoll zu beginnen und es direkt auf den Anwendungsfall zuzuschneiden; in dieser Hinsicht haben WebSockets das Problem der bidirektionalen Kommunikation bereits elegant gelöst. Um beim Laden tiefer Datei-/Skript-Hierarchien die Latenz zu verringern, sind rel="preload"- oder rel="modulepreload"-Tags hervorragend und strukturell einfach.

    • HTTP/2 Push hätte genau zum selben Anwendungsfall wie Preload-Links gepasst.
      Die Idee war, dass der Server die vorab zu ladenden Inhalte per Header schickt, sodass sie schon vorgeladen werden, bevor die Link-Tags übertragen oder geparst sind. Für Seiten mit Streaming-Unterstützung wäre das weniger nützlich, aber wenn Anfragen warten, bis die vollständige HTML-Seite serverseitig gerendert ist, hätte es einen spürbaren Vorteil geben können.
    • HTTP/2 war ein neues Low-Level-Protokoll, und HTTP Push war von Anfang an keine Funktion für bidirektionale Kommunikation.
    • Ist HTTP nicht auch bidirektionale Kommunikation?