Firefox prévoit d’abandonner la prise en charge de HTTP/2 Push

 (groups.google.com)
1 points par GN⁺ 2024-09-08 | 1 commentaires | Partager sur WhatsApp
  • Firefox va désactiver HTTP/2 Push sur toutes les plateformes dans les prochains jours, en raison de sa faible utilisation et du poids croissant de la compatibilité, tout en conservant provisoirement le code d’implémentation dans l’arbre
  • Dans l’écosystème des navigateurs, la prise en charge a déjà reculé : Chrome 106 l’a désactivé en septembre 2022, et la dernière version de Safari rejette aussi les push streams lors de tests locaux
  • Chrome a invoqué la faible utilisation de HTTP/2 Push et a recommandé comme alternatives rel="preload" et 103 Early Hints
  • Firefox a maintenu cette prise en charge parce que son coût de maintenance restait limité, mais ces derniers mois, des bugs de compatibilité web propres à Firefox sont apparus à cause de HTTP/2 Push
  • Si des serveurs et des sites web utilisent le push sans tester Firefox, certains sites peuvent ne pas fonctionner uniquement dans Firefox

Plan de désactivation de HTTP/2 Push dans Firefox

  • Firefox prévoit de désactiver HTTP/2 Push sur toutes les plateformes
  • Le travail de suppression est suivi dans Bugzilla : 1915848 - Pref off HTTP/2 push
  • Pour l’instant, la fonctionnalité sera désactivée via une préférence, tandis que le code d’implémentation restera provisoirement dans l’arbre
  • La suppression complète devrait probablement intervenir avant la branche ESR 140 au printemps prochain

État de la prise en charge selon les navigateurs et raisons de la désactivation

  • Chrome

    • Chrome 106 a désactivé HTTP/2 Push en septembre 2022
    • L’état correspondant peut être consulté sur Chrome Platform Status
    • Chrome a invoqué la faible utilisation et a recommandé rel="preload" et 103 Early Hints comme alternatives

  • Safari

    • Aucun document officiel de dépréciation n’a été identifié, mais la version actuelle rejette les push streams lors de tests locaux avec un serveur Node.js

  • Firefox

    • Jusqu’ici, Firefox a continué à prendre en charge HTTP/2 Push car la charge de maintenance restait limitée
    • Ces derniers mois, des problèmes de compatibilité web affectant uniquement Firefox sont apparus à cause de HTTP/2 Push
      • Un cas connexe est bug 1915830
      • Si des serveurs et des sites web utilisent le push sans tester sur Firefox, un site peut se bloquer uniquement dans Firefox ; voir par exemple bug 1913100

À lire aussi

1 commentaires

 
GN⁺ 2024-09-08
Avis sur Hacker News

  • Même après la « découverte soudaine » que HTTP/2 Push ne fonctionnait finalement pas, il est agaçant de voir qu’aucune excuse n’est adressée aux personnes qui expliquaient depuis longtemps pourquoi ça ne marcherait pas et qui ont été ignorées.
    Pendant des années, l’ambiance était de dire que, puisque les gens plus intelligents de Google en avaient besoin, il fallait l’intégrer à la spécification ; or il faudrait aborder les spécifications avec bien plus de prudence. Il faut arrêter d’y ajouter sans cesse des objectifs d’extension spéculatifs que certains chez Google trouvent judicieux.

    • Améliorer HTTP et les performances du Web ne semble pas vouloir dire grand-chose. On dispose déjà d’assez de bande passante pour le streaming vidéo 1080p, d’une latence suffisamment faible pour jouer en temps réel, et les CPU sont 1000 fois plus puissants qu’à l’époque où l’on s’est connecté pour la première fois à Internet.
      Ce qui ralentit les navigateurs, ce sont surtout les pubs, traqueurs et autres bricoles qui alourdissent les sites ; et ce qui corrige cela, ce n’est pas une invention de Google, mais uBlock Origin. De nos jours, ce que Google pousse dans les standards du Web semble destiné non pas aux développeurs ordinaires, mais à ajouter davantage de publicité ou à économiser 0,1 % de coûts de datacenter.
    • Quand on disait depuis longtemps que, pour des usages Web non graphiques — par exemple une recherche d’information rapide et non interactive —, le pipelining HTTP/1.1 était plus satisfaisant que HTTP/2, on se faisait souvent downvoter et répondre avec sarcasme sur HN.
      HTTP/2 ressemble à un cas où une entreprise continue de contrôler l’accès au www, une ressource publique, dans son propre intérêt. Si vous utilisez Chrome, vous êtes amené à essayer HTTP/2, et la même entreprise contrôle le moteur de recherche, le matériel, le navigateur, et maintenant même le protocole réseau. HTTP/2 peut pratiquement être vu comme HTTP/Chrome.
    • Il faut comprendre que ces personnes avaient vraiment besoin de supports pour leur promotion annuelle.
    • Avoir raison trop tôt, c’est comme avoir tort.

  • Les explications avancées pour expliquer l’échec de HTTP/2 Push ne m’ont jamais paru convaincantes. Google renvoie généralement à l’article de Jake Archibald, mais celui-ci ressemble davantage à une liste de la médiocrité des implémentations dans les navigateurs qu’à une démonstration de l’impossibilité du protocole lui-même.
    Les navigateurs prennent déjà en charge les liens preload, qui devraient jouer pratiquement le même rôle qu’un en-tête Push. Les difficultés d’implémentation de 2017, comme le cache ou les en-têtes d’authentification, posent aussi la question de savoir pourquoi le code existant de traitement du preload n’a pas pu être réutilisé.
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • Un en-tête Preload ne peut pas être considéré comme « pratiquement identique » à HTTP/2 Push. Le résultat peut être similaire, mais le mode de fonctionnement est différent ; au-delà de l’aspect très superficiel consistant à employer le mot « Preload », c’est assez différent.
      HTTP/2 Push consiste pour le serveur à pousser de manière proactive vers le client les ressources qu’il estime nécessaires, afin d’économiser un aller-retour ; l’objectif est de réduire la latence en envoyant les ressources indépendamment du pipeline DOM→rendu. Un en-tête Preload permet au serveur d’indiquer, avec le corps de la réponse, les ressources à charger en parallèle afin qu’elles soient récupérées avant le parsing ou l’évaluation du JS. 103 Early Hints envoie des indications Preload avant la fin de la génération de la réponse, avant même le premier octet du corps, afin d’avancer encore l’étape de récupération.
      La différence essentielle est de savoir si l’initiative vient du serveur ou du client, et si cela arrive avec le corps ou avant le premier octet. La raison la plus simple pour laquelle HTTP/2 Push atteint mal son objectif, c’est le cache. Le navigateur ne demande pas les ressources qu’il possède déjà, mais le serveur ne sait pas ce qui se trouve dans le cache du client. Avec Push, le risque d’envoyer des ressources inutiles est élevé ; avec 103/Preload, même en cas d’erreur, le gaspillage se limite à quelques octets d’en-têtes inutiles, ce qui est plus simple à implémenter et moins coûteux.
    • Ma compréhension de la spécification Push était aussi rouillée que la spécification elle-même. J’avais oublié que le serveur pousse réellement le contenu complet qu’il prévoit comme nécessaire au client, et je pensais à tort que seuls des en-têtes suggérant des dépendances, comme avec les liens preload, étaient inclus dans la requête.
    • Pour des raisons de sécurité, les ressources poussées doivent être traitées comme un cas particulier jusqu’à ce que la page les récupère, ce qui implique notamment un cache séparé.
    • Ce qui rend l’excuse de la suppression de Push particulièrement ridicule, c’est que les développeurs n’ont quasiment jamais eu l’occasion de l’exploiter correctement. Ils ne pouvaient ni voir les Push entrants ni y réagir.
      https://github.com/whatwg/fetch/issues/51
      Il me semble qu’il restait encore beaucoup d’opportunités, même pour le cas d’usage de distribution de contenu sur lequel tout le monde se concentrait. Il n’y a pas eu beaucoup de tentatives visibles publiquement, et peu de gens ont eu accès à des bibliothèques ou à des points de départ permettant d’expérimenter ce qu’il fallait pousser.

  • Avec le démarrage 0-RTT de HTTP/3, on peut récupérer une partie de la vitesse, et avec 103 Early Hints, le navigateur peut précharger les assets plus tôt. Cette combinaison a aussi l’avantage d’être rétrocompatible sémantiquement avec HTTP/1. Elle est également plus facile à gérer dans les reverse proxies ou les load balancers.

  • Je suis un peu déçu de voir HTTP/2 Push finir par disparaître. L’idée était élégante, mais son adoption par les frameworks a été faible, et c’est une fonctionnalité qui aurait mérité plus d’attention.
    Côté .NET, elle n’a finalement jamais été livrée, et nginx avait une implémentation de base. L’absence de cache digest a aussi constamment freiné le tout. Chrome l’a supprimée en partie au motif que « personne ne s’en apercevra de toute façon », et il semble qu’il était plus important de tout reconcevoir autour d’UDP, qui fonctionne toujours merveilleusement bien avec le NAT.

    • Je n’ai jamais eu de problèmes avec UDP et le NAT, mais si cela énerve les gens au point de favoriser la migration vers IPv6, je sourirai discrètement.

  • Quand j’avais discuté avec Mike Belshe avant la standardisation de HTTP/2, il était déjà question de retirer cette fonctionnalité de H2, car ses bénéfices étaient difficiles à concrétiser et elle comportait beaucoup de problèmes et de pièges.
    L’un des plus gros problèmes était le Push excessif : envoyer des choses déjà présentes dans le cache du navigateur, ou trop de contenu sans importance. J’ai effectivement vu de très mauvais cas où Push ralentissait le chargement des pages. Il y avait aussi des propositions pour que le navigateur indique au serveur ce qui se trouvait dans son cache local, mais elles se sont heurtées à plusieurs problèmes. HTTP Early Hints et Resource Hints ont largement remplacé le besoin de H2 Push ; ils sont beaucoup plus simples à implémenter, évitent les récupérations inutiles et sont plus faciles à comprendre.

  • On peut aussi interpréter cela comme « si les serveurs web et les sites web utilisent Push sans tester sous Firefox, le site peut se bloquer uniquement dans Firefox », mais d’autres lectures sont possibles
    Alors que les autres navigateurs refusent HTTP/2 Push et l’ignorent silencieusement, Firefox échoue lourdement dans certains cas limites. Par exemple, il est question de « Firefox semble réinitialiser la connexion lorsqu’il rencontre des majuscules dans les noms d’en-têtes »

    • Cette interprétation ne colle pas vraiment. Les autres navigateurs n’ont pas implémenté la spécification, tandis que Firefox l’a implémentée. La spécification est très claire sur la manière de traiter cette violation, et ce sont ces implémentations de serveurs web et de sites web qui sont cassées. Si elles avaient été testées avec un client conforme à la spécification, on aurait su qu’elles étaient cassées
    • L’article le dit clairement. Le coût de prise en charge de HTTP/2 Push par Firefox n’était pas très élevé jusqu’à récemment, donc il l’a conservée, mais ces derniers mois des bugs de compatibilité web n’affectant que Firefox sont apparus via HTTP/2 Push
      Cet article semble décrire précisément la mesure consistant à refuser H2 Push comme les autres navigateurs et à l’ignorer silencieusement ; il ne donne pas l’impression de cacher quoi que ce soit
    • L’inverse aurait très bien pu se produire aussi. Une nouvelle spécification n’est implémentée que dans un seul navigateur — souvent Chrome la publie d’abord de manière incomplète — puis un serveur l’implémente mal et le même problème survient

  • Je me demande pourquoi Push n’a pas été adopté plus largement. Malgré ses gros défauts, c’était l’une des principales raisons pour lesquelles HTTP/2 était considéré comme une fonctionnalité capable de changer la donne
    Je ne sais pas si c’était dû au manque de prise en charge par les navigateurs, ou si cela s’accordait mal avec les CDN

    • La raison pour laquelle Server Push n’a pas été déployé à grande échelle, c’est qu’il peut être néfaste. Le serveur pousse des ressources dont le client pourrait avoir besoin, mais ces ressources peuvent déjà se trouver dans le cache du client
      Dans ce dernier cas, c’est une charge nuisible, surtout sur mobile. Le serveur ne peut jamais savoir avec certitude si le client a réellement besoin de cette ressource. Early Hints est probablement préférable : le serveur indique rapidement les ressources nécessaires, et le client peut décider s’il doit les récupérer ou s’il les a déjà
    • J’ai envisagé de l’utiliser, puis j’ai changé d’avis. Quand une requête arrive pour Index.html, on voudrait généralement pousser script.js et style.css, mais cela revient à envoyer plusieurs centaines de kbit
      Si l’utilisateur redemande index.html, faut-il tout renvoyer ? Les ressources sont très probablement déjà dans son cache. Si on ne les envoie pas, comment savoir quoi envoyer ? Seul le navigateur sait ce qui est ou non dans le cache. Au final, le choix revient à accélérer la première visite tout en gaspillant de la bande passante lors des visites suivantes, ou à laisser la première visite plus lente et accélérer les revisites
    • Cela aurait peut-être pu changer la donne, mais surtout pour des entreprises à l’échelle de Google/Amazon/Meta, ou à peine plus petites
      Pour la plupart des autres, c’était une énorme augmentation de la complexité, et cela a été pratiquement ignoré
    • L’analyse plus détaillée publiée quand Chrome a décidé d’arrêter la prise en charge de Push peut être utile
      https://developer.chrome.com/blog/removing-push/
    • J’ai l’impression qu’on ne lui a pas laissé assez de temps. Ce n’est qu’en 2015, quand la RFC HTTP/2 a été finalisée, qu’est sortie la première version d’Apache incluant la prise en charge de HTTP/2, et en 2017 il existait encore des divergences entre navigateurs dans la manière de gérer Server Push
      La prise en charge de Push dans nginx semble être arrivée vers 2018, d’après Wikipédia. Il faut du temps pour que ce type de changement descende jusqu’aux versions des distributions stables et aux configurations par défaut. J’ai moi-même activé HTTP/2 sur mon serveur Apache pour la première fois en 2020, et il est possible qu’en 2024 certains serveurs applicatifs ne le prennent toujours pas directement en charge

  • … dans Firefox, donc

    • On dirait qu’il a déjà été supprimé partout ailleurs

  • Cela semble être des articles connexes. Y en a-t-il d’autres ?
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - août 2022, 201 commentaires
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - juillet 2022, 2 commentaires
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - décembre 2020, 168 commentaires
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - novembre 2020, 133 commentaires
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - septembre 2020, 2 commentaires
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - janvier 2020, 71 commentaires
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - octobre 2018, 16 commentaires
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - février 2018, 63 commentaires
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - juillet 2017, 23 commentaires
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - mai 2017, 20 commentaires
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - avril 2017, 59 commentaires
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - mars 2017, 2 commentaires
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - février 2017, 9 commentaires
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - août 2016, 6 commentaires
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - août 2016, 25 commentaires
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - août 2016, 2 commentaires
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - février 2016, 13 commentaires

  • Rien d’étonnant. Quand on ajoute, par-dessus un protocole existant conçu pour un objectif précis, une fonctionnalité qui n’a presque rien à voir avec ses objectifs de conception initiaux, c’est généralement ce qui arrive.
    La plupart du temps, il vaut mieux partir d’un protocole de bas niveau et l’adapter directement au cas d’usage ; de ce point de vue, WebSockets a déjà résolu élégamment le problème de la communication bidirectionnelle. Pour réduire la latence lors du chargement d’arborescences profondes de fichiers/scripts, les balises rel="preload" ou rel="modulepreload" offrent une structure excellente et simple.

    • HTTP/2 Push aurait correspondu exactement au même cas d’usage que les liens preload réduisant la latence.
      L’idée était que le serveur envoie dans les en-têtes le contenu à précharger, afin qu’il soit préchargé avant même que la balise de lien ne soit transmise ou analysée. Ce serait moins utile pour les pages prenant en charge le streaming, mais quand la requête reste bloquée jusqu’à ce que toute la page HTML soit rendue côté serveur, cela aurait pu apporter un gain notable.
    • HTTP/2 était un nouveau protocole de bas niveau, et HTTP Push n’était pas, à l’origine, une fonctionnalité de communication bidirectionnelle.
    • HTTP n’est-il pas aussi de la communication bidirectionnelle ?