Firefox, HTTP/2 Push desteğini sonlandırmayı planlıyor

 (groups.google.com)
1 puan yazan GN⁺ 2024-09-08 | 1 yorum | WhatsApp'ta paylaş
  • Firefox, düşük kullanım oranı ve artan uyumluluk yükü nedeniyle HTTP/2 Push’ı birkaç gün içinde tüm platformlarda devre dışı bırakacak; uygulama kodu ise bir süre daha ağaçta kalacak
  • Tarayıcı ekosisteminde destek zaten azalmış durumda; Chrome 106 bunu Eylül 2022’de kapatmıştı, Safari’nin güncel sürümü de yerel testlerde push stream’lerini reddediyor
  • Chrome, HTTP/2 Push’ın düşük kullanımını gerekçe göstermiş ve alternatif olarak rel="preload" ile 103 Early Hints’i önermişti
  • Firefox, bakım maliyeti çok yüksek olmadığı için desteği sürdürmüştü; ancak son birkaç ayda HTTP/2 Push nedeniyle yalnızca Firefox’ta ortaya çıkan web uyumluluğu hataları görüldü
  • Sunucular ve web siteleri push kullanıp Firefox testini atladığında, bazı siteler yalnızca Firefox’ta çalışmayabilir

Firefox’un HTTP/2 Push’ı devre dışı bırakma planı

  • Firefox, tüm platformlarda HTTP/2 Push’ı devre dışı bırakmayı planlıyor
  • Kaldırma çalışması Bugzilla’daki 1915848 - Pref off HTTP/2 push üzerinden izleniyor
  • Şimdilik bir preference ile kapatılacak, uygulama kodu bir süre daha ağaçta kalacak
  • Tam kaldırmanın gelecek ilkbaharda ESR 140 dalından önce gerçekleşmesi muhtemel

Tarayıcılara göre destek durumu ve devre dışı bırakma nedeni

  • Chrome

    • Chrome 106, Eylül 2022’de HTTP/2 Push’ı devre dışı bıraktı
    • İlgili durum Chrome Platform Status üzerinden görülebilir
    • Chrome, düşük kullanımı gerekçe gösterdi ve alternatif olarak rel="preload" ile 103 Early Hints’i önerdi

  • Safari

    • Resmî bir deprecation dokümanı doğrulanamadı; ancak mevcut sürüm, Node.js sunucusu kullanılan yerel testlerde push stream’lerini reddediyor

  • Firefox

    • Firefox, bakım yükü büyük olmadığı için şimdiye kadar HTTP/2 Push desteğini sürdürdü
    • Son birkaç ayda HTTP/2 Push nedeniyle yalnızca Firefox’u etkileyen web uyumluluğu sorunları ortaya çıktı
      • İlgili örneklerden biri bug 1915830
      • Sunucular ve web siteleri push kullanırken Firefox’ta test etmezse site yalnızca Firefox’ta takılıp kalabilir; buna örnek olarak bug 1913100 gösterilebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-08
Hacker News yorumları

  • HTTP/2 Push'ın sonuçta işe yaramadığını gösteren “ani keşif”ten sonra bile, eskiden beri bunun neden olmayacağını açıklayıp görmezden gelinen insanlara hiçbir özür dilenmemesi sinir bozucu.
    Google'daki daha akıllı insanların buna ihtiyaç duyduğunu söyleyip spesifikasyona zorla sokalım havası yıllarca sürdü; spesifikasyonlara çok daha muhafazakâr yaklaşılmalı. Google'ın bir kısmının iyi fikir sandığı spekülatif genişleme hedeflerini sürekli ekleme alışkanlığı bırakılmalı.

    • HTTP'yi ve web performansını iyileştirmenin pek anlamı yok gibi görünüyor. Zaten 1080p video akışı yapmaya yetecek bant genişliğimiz, gerçek zamanlı oyun oynayacak kadar düşük gecikmemiz var; CPU'lar da internete ilk bağlandığım zamana göre 1000 kat güçlü.
      Tarayıcıyı yavaşlatan şey çoğunlukla siteleri ezen reklamlar, izleyiciler ve ıvır zıvır; bunu düzeltmek için kullanılan da Google icadı değil, uBlock Origin. Google'ın bugünlerde web standartlarına soktuğu şeyler sıradan geliştiriciler için değil, daha fazla reklam koymak ya da veri merkezi maliyetinden %0,1 tasarruf etmek içinmiş gibi görünüyor.
    • Eskiden beri grafik dışı web kullanımı, örneğin hızlı ve etkileşimsiz bilgi arama için HTTP/1.1 pipelining'in HTTP/2'den daha tatmin edici olduğunu söylediğimde HN'de downvote ve alaycı cevaplar alırdım.
      HTTP/2, bir şirketin kamu kaynağı olan www erişimini kendi çıkarlarına göre kontrol etmeye devam etmesinin bir örneği gibi görünüyor. Chrome kullanınca HTTP/2 deneniyor; aynı şirket arama motorunu, donanımı, tarayıcıyı ve şimdi de ağ protokolünü kontrol ediyor. HTTP/2'ye fiilen HTTP/Chrome denebilir.
    • O insanların yıllık terfi dosyalarına gerçekten ihtiyaç duyduğunu anlayışla karşılayın.
    • Fazla erken haklı çıkmak, yanılmakla aynıdır.

  • HTTP/2 Push'ın neden başarısız olduğuna dair sunulan açıklamalar bana hiç ikna edici gelmedi. Google genelde Jake Archibald'ın yazısına işaret ediyor ama o yazı protokolün kendisinin neden işlemediğini göstermekten çok, tarayıcı uygulamasının ne kadar kötü olduğunu listelemeye yakın görünüyor.
    Tarayıcılar zaten preload linklerini destekliyor ve bunlar Push header'ıyla fiilen aynı işi yapmalı. Önbellekleme ya da kimlik doğrulama header'ları gibi 2017 uygulamasındaki zorluklarda da mevcut preload işleme kodunun yeniden kullanılamayıp kullanılamayacağı merak konusu.
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • Preload header HTTP/2 Push ile “fiilen aynı” sayılamaz. Sonuç benzer olabilir ama çalışma biçimi farklıdır; “Preload” kelimesini kullanmaları gibi çok yüzeysel bir nokta dışında epey farklılar.
      HTTP/2 Push, sunucunun istemcinin ihtiyaç duyacağını düşündüğü kaynakları proaktif olarak itip bir gidiş-dönüşü azaltmasıdır; hedef, DOM→render pipeline'ından bağımsız olarak kaynak gönderip gecikmeyi düşürmektir. Preload header ise sunucunun gövdeyle birlikte paralel yüklenecek kaynakları bildirmesi ve bunların parsing ya da JS değerlendirmesinden önce alınmasını sağlamasıdır. 103 Early Hints, yanıt üretimi bitmeden, gövdenin ilk byte'ından önce Preload ipuçlarını göndererek fetch aşamasını daha da öne çeker.
      Temel fark sunucu odaklı mı istemci odaklı mı olduğu, gövdeyle birlikte mi yoksa ilk byte'tan önce mi gerçekleştiğidir. HTTP/2 Push'ın hedefe ulaşmakta zayıf kalmasının en basit nedeni önbellektir. Tarayıcı zaten sahip olduğu kaynakları istemez ama sunucu istemci önbelleğinde ne olduğunu bilmez. Push'ın gereksiz kaynak gönderme riski büyüktür; 103/Preload yanlış çıksa bile boşa giden şey birkaç byte'lık işe yaramaz header'dan ibarettir, bu yüzden uygulaması da kolay, maliyeti de düşüktür.
    • Push spesifikasyonuna dair anlayışım, spesifikasyonun kendisi kadar paslanmıştı. Sunucunun istemcinin ihtiyaç duyacağını tahmin ettiği tüm içeriği gerçekten ittiğini unutmuş, preload linkleri gibi yalnızca bağımlılığı ima eden header'ların isteğe dahil edildiğini sanmıştım.
    • Güvenlik açısından, itilmiş kaynaklar sayfa onları alana kadar özel bir durum olarak ele alınmalı; bunun bir parçası olarak ayrı bir önbellek gerekir.
    • Push'ın kaldırılmasına gösterilen gerekçe özellikle gülünç, çünkü geliştiriciler baştan Push'ı doğru dürüst kullanma fırsatını neredeyse hiç elde edemedi. Gelen Push'ı göremiyor, ona tepki veremiyorlardı.
      https://github.com/whatwg/fetch/issues/51
      Herkesin odaklandığı içerik teslimi kullanım senaryosunda da hâlâ çok fırsat varmış gibi görünüyor. Kamuya açık görünen deneme de fazla yoktu; neyin Push edilmesi gerektiğini denemeye yarayacak kütüphanelere veya başlangıç noktalarına erişebilen kişi de çok azdı.

  • HTTP/3 0-RTT başlangıcı ile hızın bir kısmı geri kazanılabilir; 103 Early Hints ile de tarayıcının varlıkları erkenden önceden yüklemesi sağlanabilir. Bu kombinasyonun HTTP/1 ile anlamsal olarak geriye dönük uyumlu olması gibi bir avantajı da var. Reverse proxy'lerde ve load balancer'larda da yönetmesi kolay.

  • HTTP/2 Push'ın sonunda ortadan kalktığını görmek biraz üzücü. Fikir temizdi ama framework'lerin benimsemesi zayıf kaldı; daha fazla ilgi görse iyi olurdu.
    .NET tarafı bunu nihayetinde hiç yayımlamadı, nginx'te ise temel bir uygulama vardı. Cache digest'in olmaması da sürekli ayak bağı oldu. Chrome bunu kaldırırken gerekçelerin bir kısmında “nasıl olsa kimse fark etmeyecek” tarzı bir çizgi izledi; demek ki NAT üzerinde her zaman harika çalışan UDP ile her şeyi yeniden tasarlamak daha önemliymiş.

    • UDP ve NAT yüzünden hiç sorun yaşamadım ama bu insanları sinir edip IPv6'ya geçişi teşvik edecekse sessizce gülerim.

  • HTTP/2 standartlaşmadan önce Mike Belshe ile konuştuğumda bile, bu özelliğin faydasını hayata geçirmenin zor olduğu, çok sayıda sorun ve tuzak barındırdığı için H2'den çıkarılması yönünde zaten bir hava vardı.
    En büyük sorunlardan biri, tarayıcı önbelleğinde zaten olan şeyleri göndermek ya da önemsiz içeriği aşırı miktarda göndermek anlamına gelen aşırı Push idi. Gerçekten de Push yüzünden sayfa yüklemesinin daha yavaşladığı çok kötü örnekler gördüm. Tarayıcının yerel önbelleğinde ne olduğunu sunucuya bildirmesine dair öneriler de vardı ama çeşitli sorunlara çarptılar. HTTP Early Hints ve Resource Hints, H2 Push'a duyulan ihtiyacı büyük ölçüde ortadan kaldırdı; uygulaması çok daha kolay, gereksiz fetch'leri önlüyor ve anlaşılması da daha basit.

  • “Web sunucusu ve web sitesi Push kullanırken Firefox’ta test etmezse site yalnızca Firefox’ta takılabilir” şeklinde yorumlamak da mümkün, ama başka yorumlar da mümkün.
    Diğer tarayıcılar HTTP/2 Push’u reddedip sessizce yok sayarken, Firefox bazı sınır koşullarında sert biçimde devriliyor. Örneğin “Firefox, başlık adında büyük harf görünce bağlantıyı sıfırlıyor gibi” deniyor.

    • Bu yorum pek oturmuyor. Diğer tarayıcılar spesifikasyonu uygulamamış; Firefox ise spesifikasyonu uyguluyor. Spesifikasyon bu ihlalin nasıl ele alınması gerektiği konusunda çok net ve bozuk olan o web sunucusu ile web sitesi uygulaması. Spesifikasyona uyan bir istemciyle test edilmiş olsaydı bozuk olduğu anlaşılırdı.
    • Yazıda açıkça söyleniyor. Firefox’ta HTTP/2 Push desteğinin maliyeti yakın zamana kadar yüksek olmadığı için destek sürdürülmüş, ancak son birkaç ayda HTTP/2 Push üzerinden yalnızca Firefox’u etkileyen web uyumluluğu hataları ortaya çıkmış.
      Bu yazı, diğer tarayıcılar gibi H2 Push’u reddedip sessizce yok sayma yönündeki tam da bu adımı açıklıyor gibi görünüyor; bir şey saklanıyormuş gibi durmuyor.
    • Tersi de pekâlâ yaşanabilirdi. Yeni bir spesifikasyonun yalnızca tek bir tarayıcıda uygulanması, genellikle Chrome’un önce eksik bir biçimde yayımlaması ve sunucunun bunu yanlış uygulayıp aynı soruna yol açması gibi.

  • Push’un neden daha yaygın benimsenmediğini merak ediyorum. Büyük kusurlarına rağmen HTTP/2’nin oyunu değiştirecek bir özellik sayılmasının önemli nedenlerinden biriydi.
    Sorun tarayıcı desteğinin eksikliği miydi, yoksa CDN’lerle pek uyumlu olmaması mıydı bilmiyorum.

    • Server Push’un büyük ölçekte dağıtılmamasının nedeni zararlı olabilmesi. Sunucu, istemcinin ihtiyaç duyabileceği varlıkları iter; ancak bu varlıklar zaten istemcinin önbelleğinde olabilir.
      İkinci durumda, özellikle mobilde bu zararlı bir yük hâline gelir. Sunucu, o varlığın istemci için gerçekten gerekli olup olmadığını asla kesin olarak bilemez. Early Hints muhtemelen daha iyidir; sunucu gerekli varlıkları hızlıca bildirir, istemci de alıp almayacağına veya zaten elinde olup olmadığına karar verebilir.
    • Kullanmayı değerlendirdim ama sonra vazgeçtim. Index.html isteği geldiğinde normalde script.js ve style.css göndermek istersiniz; bu da yüzlerce kbit göndermek demektir.
      Kullanıcı tekrar index.html isterse hepsini yine göndermek mi gerekir? Kaynakların zaten kullanıcının önbelleğinde olma ihtimali yüksek. Göndermeyeceksek ne göndereceğimizi nasıl bileceğiz? Önbellekte neyin olup olmadığını yalnızca tarayıcı bilir. Sonuçta seçenekler, ilk ziyareti hızlandırıp tekrar ziyaretlerde bant genişliği israf etmek ya da ilk ziyareti yavaş bırakıp tekrar ziyaretleri hızlandırmak oluyor.
    • Oyunu değiştiren bir özellik olabilirdi, ama bu Google/Amazon/Meta ölçeğindeki ya da onlardan biraz daha küçük şirketler için geçerliydi.
      Geri kalanların çoğu için devasa bir karmaşıklık artışıydı ve fiilen yok sayıldı.
    • Chrome Push desteğini sonlandırmaya karar verdiğinde yayımladığı daha ayrıntılı analiz faydalı olabilir.
      [https://developer.chrome.com/blog/removing-push/](https://developer.chrome.com/blog/removing-push/）
    • Yeterince zaman tanınmadı gibi geliyor. HTTP/2 RFC’sinin tamamlandığı 2015’te, HTTP/2 desteğini içeren ilk Apache sürümü ancak çıkmıştı; 2017’de bile Server Push’un nasıl ele alınacağı konusunda tarayıcılar arasında uyumsuzluklar vardı.
      nginx’in Push desteği, Vikipedi’ye göre 2018 civarında eklenmiş görünüyor. Bu tür değişikliklerin kararlı dağıtım sürümlerine ve varsayılan ayarlara kadar inmesi zaman alır. Benim Apache sunucumda HTTP/2’yi ilk açmam da 2020’deydi; 2024’te bile bunu doğrudan desteklemeyen uygulama sunucuları olması muhtemel.

  • … Firefox’ta yani.

    • Zaten başka yerlerde tamamen kaldırılmış gibi görünüyor.

  • İlgili yazılar gibi görünüyor. Daha fazlası var mı?
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - Ağustos 2022, 201 yorum
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - Temmuz 2022, 2 yorum
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - Aralık 2020, 168 yorum
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - Kasım 2020, 133 yorum
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - Eylül 2020, 2 yorum
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - Ocak 2020, 71 yorum
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - Ekim 2018, 16 yorum
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - Şubat 2018, 63 yorum
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - Temmuz 2017, 23 yorum
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - Mayıs 2017, 20 yorum
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - Nisan 2017, 59 yorum
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - Mart 2017, 2 yorum
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - Şubat 2017, 9 yorum
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - Ağustos 2016, 6 yorum
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - Ağustos 2016, 25 yorum
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - Ağustos 2016, 2 yorum
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - Şubat 2016, 13 yorum

  • Şaşırtıcı değil. Belirli bir amaç için yapılmış mevcut bir protokolün üzerine, asıl tasarım hedefiyle pek ilgisi olmayan bir özellik eklersen genelde böyle olur
    Çoğu zaman düşük seviyeli bir protokolden başlayıp doğrudan kullanım senaryosuna uyarlamak daha iyidir; bu açıdan WebSockets'in çift yönlü iletişim sorununu zaten zarif biçimde çözdüğünü düşünüyorum. Derin dosya/script hiyerarşilerini yüklerken gecikmeyi azaltmak için rel="preload" veya rel="modulepreload" etiketleri harika ve basit bir yapı sunuyor

    • HTTP/2 Push, gecikmeyi azaltan preload bağlantıları ile tam olarak aynı kullanım senaryosuna uymuş olurdu
      Esas fikir, sunucunun önceden yüklenmesi gereken içeriği header olarak gönderip, link etiketi aktarılmadan veya parse edilmeden önce önceden yükletmesiydi. Streaming destekleyen sayfalarda daha az kullanışlı olurdu, ama tüm HTML sayfasının sunucu tarafında render edilmesi bitene kadar isteğin beklediği durumlarda gözle görülür bir kazanç sağlayabilirdi
    • HTTP/2 yeni bir düşük seviyeli protokoldü ve HTTP Push baştan beri çift yönlü iletişim ile ilgili bir özellik değildi
    • HTTP de çift yönlü iletişim değil mi?