Firefox planea dejar de dar soporte a HTTP/2 Push

 (groups.google.com)
1 puntos por GN⁺ 2024-09-08 | 1 comentarios | Compartir por WhatsApp
  • Firefox desactivará HTTP/2 Push en todas las plataformas en los próximos días debido a su bajo uso y a la creciente carga de compatibilidad, y por ahora dejará el código de implementación en el árbol
  • En el ecosistema de navegadores, el soporte ya se ha reducido: Chrome 106 lo desactivó en septiembre de 2022, y la versión más reciente de Safari también rechaza push streams en pruebas locales
  • Chrome citó el bajo uso de HTTP/2 Push y recomendó como alternativas rel="preload" y 103 Early Hints
  • Firefox había mantenido el soporte porque su costo de mantenimiento no era alto, pero en los últimos meses han aparecido bugs de compatibilidad web que solo ocurren en Firefox por culpa de HTTP/2 Push
  • Si servidores y sitios web usan push y omiten probar en Firefox, algunos sitios podrían dejar de funcionar solo en Firefox

Plan de Firefox para desactivar HTTP/2 Push

  • Firefox planea desactivar HTTP/2 Push en todas las plataformas
  • El trabajo se sigue en Bugzilla: 1915848 - Pref off HTTP/2 push
  • Por ahora se apagará mediante una preferencia, y el código de implementación permanecerá en el árbol durante algún tiempo
  • Es muy probable que la eliminación completa ocurra antes de la rama ESR 140 de la próxima primavera

Estado del soporte por navegador y motivos de la desactivación

  • Chrome

    • Chrome 106 desactivó HTTP/2 Push en septiembre de 2022
    • El estado relacionado puede verse en Chrome Platform Status
    • Chrome citó su bajo uso y recomendó como alternativas rel="preload" y 103 Early Hints

  • Safari

    • No se pudo confirmar documentación oficial de deprecación, pero la versión actual rechaza push streams en pruebas locales usando un servidor Node.js

  • Firefox

    • Firefox había seguido dando soporte a HTTP/2 Push porque la carga de mantenimiento no era alta
    • En los últimos meses, HTTP/2 Push ha provocado problemas de compatibilidad web que afectan solo a Firefox
      • Un caso relacionado es bug 1915830
      • Si servidores y sitios web usan push sin probar en Firefox, un sitio puede quedarse bloqueado solo en Firefox; un ejemplo es bug 1913100

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-09-08
Opiniones en Hacker News

  • Es molesto que, incluso después del “descubrimiento repentino” de que HTTP/2 Push al final no funcionaba, no haya ninguna disculpa para quienes desde hace tiempo explicaban por qué no iba a funcionar y fueron ignorados.
    Durante años hubo un ambiente de “si la gente más inteligente de Google dice que hace falta, metámoslo en la especificación”, cuando habría que abordar las especificaciones con mucha más cautela. Hay que dejar de meter continuamente objetivos de expansión especulativos que alguna parte de Google considera buenos.

    • Mejorar HTTP y el rendimiento de la web parece no tener mucho sentido. Ya tenemos suficiente ancho de banda para hacer streaming de video 1080p, latencia lo bastante baja para jugar en tiempo real, y CPUs 1000 veces más potentes que cuando nos conectamos por primera vez a internet.
      Lo que vuelve lentos a los navegadores son, en su mayoría, los anuncios, rastreadores y basura que aplastan a los sitios, y lo que se usa para arreglar eso no es un invento de Google sino uBlock Origin. Lo que Google empuja últimamente en los estándares web no parece ser para desarrolladores comunes, sino para meter más anuncios o ahorrar 0,1% en costos de centros de datos.
    • Desde hace tiempo, cuando decía en HN que para usos web no gráficos, por ejemplo búsquedas de información rápidas y no interactivas, HTTP/1.1 pipelining me resultaba más satisfactorio que HTTP/2, recibía downvotes y respuestas sarcásticas.
      HTTP/2 parece un caso de una empresa intentando seguir controlando, según sus propios intereses, el acceso a un recurso público como la www. Si usas Chrome, te hace probar HTTP/2, y la misma empresa controla el motor de búsqueda, el hardware, el navegador y ahora hasta el protocolo de red. HTTP/2 prácticamente podría verse como HTTP/Chrome.
    • Hay que entender que esa gente de verdad necesitaba material para su ascenso anual.
    • Acertar demasiado temprano es lo mismo que equivocarse.

  • Nunca me parecieron convincentes las explicaciones que se dieron sobre por qué HTTP/2 Push fracasó. Google suele apuntar al artículo de Jake Archibald, pero ese texto parece más una lista de lo pobre que fue la implementación en los navegadores que una explicación de por qué el protocolo en sí no funciona.
    Los navegadores ya admiten enlaces preload, que en la práctica deberían cumplir casi el mismo papel que los encabezados Push. También me pregunto si las dificultades de implementación de 2017, como caché o encabezados de autenticación, no podrían haber reutilizado el código existente de manejo de preload.
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • Los encabezados Preload no pueden considerarse “prácticamente iguales” a HTTP/2 Push. Los resultados pueden parecerse, pero el modo de operación es distinto y, salvo la parte muy superficial de usar la palabra “Preload”, son bastante diferentes.
      HTTP/2 Push consiste en que el servidor envía de forma proactiva recursos que cree que el cliente necesitará, reduciendo un viaje de ida y vuelta, y su objetivo es reducir la latencia enviando recursos independientemente del pipeline DOM→renderizado. El encabezado Preload consiste en que el servidor informa, junto con el cuerpo, qué recursos cargar en paralelo para que se obtengan antes del parseo o la evaluación de JS. 103 Early Hints envía pistas Preload antes de que termine de generarse la respuesta, antes del primer byte del cuerpo, adelantando aún más la fase de obtención.
      La diferencia clave está en si es dirigido por el servidor o por el cliente, y si ocurre junto con el cuerpo o antes del primer byte. La razón más simple por la que HTTP/2 Push es débil para cumplir su objetivo es la caché. El navegador no solicita recursos que ya tiene, pero el servidor no sabe qué hay en la caché del cliente. Push tiene un alto riesgo de enviar recursos innecesarios, mientras que con 103/Preload, si se equivoca, solo se desperdician unos pocos bytes de encabezados inútiles, por lo que es más fácil de implementar y de menor costo.
    • Mi comprensión de la especificación de Push estaba tan oxidada como la propia especificación. Había olvidado que el servidor realmente empuja el contenido completo que espera que el cliente necesite, y había asumido erróneamente que, como con un enlace preload, solo se incluía en la solicitud un encabezado que insinuaba la dependencia.
    • Por seguridad, los recursos empujados deben tratarse como un caso especial hasta que la página los tome, y uno de esos casos requiere una caché separada.
    • La excusa para eliminar Push es especialmente ridícula porque los desarrolladores casi no tuvieron oportunidad de aprovecharlo bien desde el principio. No podían ver los Push entrantes ni reaccionar a ellos.
      https://github.com/whatwg/fetch/issues/51
      También parece que aún había muchas oportunidades en el caso de uso de entrega de contenido en el que todos estaban enfocados. No hubo muchos intentos visibles públicamente, y casi nadie tuvo acceso a bibliotecas o puntos de partida para experimentar con qué cosas convenía enviar por Push.

  • Con el inicio 0-RTT de HTTP/3 se puede recuperar parte de la velocidad, y con 103 Early Hints el navegador puede precargar assets antes. Esta combinación también tiene la ventaja de ser semánticamente retrocompatible con HTTP/1. Es fácil de manejar incluso en proxies inversos o balanceadores de carga.

  • Me da un poco de pena ver que HTTP/2 Push finalmente desaparezca. La idea era limpia, pero la adopción por frameworks fue pobre, y era una función que habría merecido más atención.
    En .NET al final nunca lo lanzaron, y nginx tenía algo así como una implementación básica. La falta de cache digest también siguió siendo un obstáculo. Chrome lo eliminó en parte con un razonamiento del tipo “de todos modos nadie se va a dar cuenta”, y al parecer era más importante rediseñarlo todo sobre UDP, que siempre funciona maravillosamente detrás de NAT.

    • Nunca he tenido problemas con UDP y NAT, pero si eso molesta a la gente y la empuja a la migración a IPv6, me quedaré riéndome en silencio.

  • Cuando hablé con Mike Belshe antes de que HTTP/2 se estandarizara, ya había una tendencia a quitar esta función de H2 porque era difícil materializar sus beneficios y tenía muchos problemas y trampas.
    Uno de los mayores problemas era el Push excesivo: enviar cosas que ya estaban en la caché del navegador, o mandar demasiado contenido poco importante. De hecho, vi casos bastante malos en los que Push hacía que la carga de la página fuera más lenta. También hubo propuestas para que el navegador informara al servidor qué tenía en la caché local, pero chocaron con varios problemas. HTTP Early Hints y Resource Hints sustituyeron en gran medida la necesidad de H2 Push, y son mucho más fáciles de implementar, evitan fetches innecesarios y también son más fáciles de entender.

  • También es posible interpretarlo como “si los servidores web y los sitios web usan Push y no lo prueban en Firefox, el sitio puede quedar colgado solo en Firefox”, pero también hay otras interpretaciones.
    Mientras otros navegadores rechazan HTTP/2 Push y lo ignoran silenciosamente, Firefox se cae de forma importante en algunos casos límite. Por ejemplo, se menciona que “parece que Firefox reinicia la conexión cuando encuentra mayúsculas en los nombres de encabezados”.

    • Esa interpretación no encaja bien. Los otros navegadores son los que no implementaron la especificación, y Firefox sí implementa la especificación. La especificación es muy clara sobre cómo se debe manejar esta infracción, y son esas implementaciones de servidores web y sitios web las que están rotas. Si hubieran probado con un cliente que cumple la especificación, se habrían dado cuenta de que estaba roto.
    • El artículo lo dice claramente. Firefox siguió soportándolo porque el costo de mantener HTTP/2 Push no había sido grande hasta hace poco, pero en los últimos meses surgieron bugs de compatibilidad web que solo afectan a Firefox a través de HTTP/2 Push.
      El artículo parece describir precisamente esa medida: rechazar H2 Push e ignorarlo silenciosamente, como hacen otros navegadores; no parece que estén ocultando algo.
    • También podría haber pasado perfectamente al revés. Una especificación nueva se implementa solo en un navegador —normalmente Chrome la saca primero de forma incompleta—, un servidor la implementa mal y se produce el mismo problema.

  • Me pregunto por qué Push no se adoptó más ampliamente. A pesar de sus grandes defectos, era una de las principales razones por las que HTTP/2 se consideraba una función capaz de cambiar las reglas del juego.
    No sé si fue por falta de soporte en navegadores o porque no encajaba bien con las CDN.

    • La razón por la que Server Push no se desplegó a gran escala es que puede ser perjudicial. El servidor empuja recursos que el cliente quizá necesite, pero esos recursos podrían ya estar en la caché del cliente.
      En este último caso, sobre todo en móviles, se convierte en una carga perjudicial. El servidor nunca puede saber con precisión si el cliente realmente necesita ese recurso. Early Hints probablemente sea mejor: si el servidor informa rápido qué recursos hacen falta, el cliente puede decidir si los descarga o si ya los tiene.
    • Consideré usarlo y luego cambié de opinión. Cuando llega una solicitud de Index.html, normalmente querrías empujar script.js y style.css, pero eso significa enviar cientos de kbits.
      Si el usuario vuelve a solicitar index.html, ¿habría que enviar todo otra vez? Es muy probable que los recursos ya estén en la caché del usuario. Si no los envías, ¿cómo sabes qué deberías enviar? Solo el navegador sabe qué hay y qué no hay en la caché. Al final, las opciones son acelerar la primera visita pero desperdiciar ancho de banda en las visitas posteriores, o dejar lenta la primera visita y acelerar las siguientes.
    • Puede que sí fuera una función capaz de cambiar las reglas del juego, pero eso aplicaba a empresas del tamaño de Google/Amazon/Meta, o quizá un poco más pequeñas.
      Para casi todos los demás era un enorme aumento de complejidad, y en la práctica se ignoró.
    • Puede servir ver el análisis más detallado que publicó Chrome cuando decidió dejar de soportar Push.
      https://developer.chrome.com/blog/removing-push/
    • Creo que no se le dio suficiente tiempo. Recién en 2015, cuando se terminó el RFC de HTTP/2, salió la primera versión de Apache con soporte para HTTP/2, y en 2017 todavía había inconsistencias entre navegadores en la forma de manejar Server Push.
      Según Wikipedia, el soporte de Push en nginx parece haber llegado alrededor de 2018. Estos cambios necesitan tiempo para bajar a las versiones de distribuciones estables y a las configuraciones predeterminadas. La primera vez que activé HTTP/2 en mi servidor Apache fue en 2020, y en 2024 aún es posible que haya servidores de aplicaciones que no lo soporten directamente.

  • … en Firefox, claro.

    • Parece que ya lo quitaron en todos los demás lados.

  • Parece ser contenido relacionado. ¿Habrá más?
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - agosto de 2022, 201 comentarios
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - julio de 2022, 2 comentarios
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - diciembre de 2020, 168 comentarios
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - noviembre de 2020, 133 comentarios
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - septiembre de 2020, 2 comentarios
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - enero de 2020, 71 comentarios
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - octubre de 2018, 16 comentarios
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - febrero de 2018, 63 comentarios
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - julio de 2017, 23 comentarios
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - mayo de 2017, 20 comentarios
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - abril de 2017, 59 comentarios
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - marzo de 2017, 2 comentarios
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - febrero de 2017, 9 comentarios
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - agosto de 2016, 6 comentarios
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - agosto de 2016, 25 comentarios
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - agosto de 2016, 2 comentarios
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - febrero de 2016, 13 comentarios

  • No sorprende. Cuando se agrega a un protocolo existente, creado para un propósito específico, una función que casi no tiene relación con su objetivo de diseño original, normalmente termina así
    En la mayoría de los casos conviene más partir de un protocolo de bajo nivel y adaptarlo directamente al caso de uso; en ese sentido, creo que WebSockets ya resolvió de forma elegante el problema de la comunicación bidireccional. Para reducir la latencia al cargar jerarquías profundas de archivos/scripts, las etiquetas rel="preload" o rel="modulepreload" son una estructura excelente y simple

    • HTTP/2 Push habría encajado exactamente en el mismo caso de uso que los enlaces preload con menor latencia
      La idea era que el servidor enviara en los headers el contenido que debía precargarse, para empezar a precargarlo incluso antes de que la etiqueta de enlace se transmitiera o se parseara. Sería menos útil en páginas que admiten streaming, pero cuando la solicitud queda detenida hasta que toda la página HTML se renderiza del lado del servidor, podría haber aportado una mejora visible
    • HTTP/2 era un nuevo protocolo de bajo nivel, y HTTP Push, para empezar, no era una función de comunicación bidireccional
    • ¿HTTP no es también comunicación bidireccional?