Firefox, HTTP/2 Push सपोर्ट बंद करने का इरादा

 (groups.google.com)
1 पॉइंट द्वारा GN⁺ 2024-09-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Firefox कम उपयोग और बढ़ते compatibility बोझ के कारण HTTP/2 Push को सभी platforms पर कुछ दिनों के भीतर disable करेगा, और implementation code को फिलहाल tree में रहने देगा
  • browser ecosystem में support पहले ही घट चुका है; Chrome 106 ने सितंबर 2022 में इसे बंद कर दिया था, और Safari के latest version भी local tests में push stream को reject करते हैं
  • Chrome ने HTTP/2 Push के कम usage को वजह बताया और alternative के रूप में rel="preload" और 103 Early Hints की सिफारिश की
  • Firefox maintenance cost बहुत ज्यादा न होने के कारण support जारी रखे हुए था, लेकिन हाल के महीनों में HTTP/2 Push की वजह से सिर्फ Firefox में होने वाले web compatibility bugs सामने आए
  • अगर servers और websites push का इस्तेमाल करते हुए Firefox testing छोड़ दें, तो कुछ sites सिर्फ Firefox में काम न कर सकती हैं

Firefox की HTTP/2 Push disable करने की योजना

  • Firefox सभी platforms पर HTTP/2 Push को disable करने की योजना बना रहा है
  • removal work को Bugzilla के 1915848 - Pref off HTTP/2 push में track किया जा रहा है
  • अभी इसे preference से बंद किया जाएगा, और implementation code फिलहाल tree में रहेगा
  • पूरी तरह removal अगले साल spring में ESR 140 branch से पहले होने की संभावना अधिक है

browser-wise support status और disable करने के कारण

  • Chrome

    • Chrome 106 ने सितंबर 2022 में HTTP/2 Push को disable किया
    • संबंधित status Chrome Platform Status पर देखा जा सकता है
    • Chrome ने कम usage को कारण बताया और alternative के तौर पर rel="preload" और 103 Early Hints की सिफारिश की

  • Safari

    • official deprecation material की पुष्टि नहीं हो सकी, लेकिन current version Node.js server का उपयोग करके किए गए local tests में push stream को reject करता है

  • Firefox

    • Firefox अब तक maintenance burden ज्यादा न होने के कारण HTTP/2 Push support जारी रखे हुए था
    • हाल के महीनों में HTTP/2 Push की वजह से web compatibility issues हुए जो केवल Firefox को प्रभावित करते हैं
      • संबंधित मामले के रूप में bug 1915830 है
      • यदि servers और websites push का उपयोग करते हुए Firefox पर test नहीं करते, तो site केवल Firefox में रुक सकती है; इसका उदाहरण bug 1913100 है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-08
Hacker News की राय

  • HTTP/2 Push आखिरकार काम नहीं करता—इस “अचानक खोज” के बाद भी, उन लोगों से कोई माफी नहीं मांगी गई जिन्हें पहले से यह समझाते हुए नज़रअंदाज़ किया गया था कि यह क्यों नहीं चलेगा, यह झुंझलाने वाली बात है
    कई साल तक माहौल ऐसा था कि Google के ज्यादा समझदार लोगों को इसकी जरूरत है, तो इसे specification में डाल दो; जबकि specification को कहीं ज्यादा conservative तरीके से लेना चाहिए। Google के कुछ लोगों को जो अच्छा लगा, ऐसे speculative stretch goals लगातार जोड़ना बंद होना चाहिए

    • HTTP और web performance सुधारने की बात अब बहुत मायने रखती नहीं दिखती। हमारे पास पहले ही 1080p video streaming के लिए पर्याप्त bandwidth है, real-time games के लिए latency कम है, और जब पहली बार online आए थे उसकी तुलना में CPU 1000 गुना ताकतवर हैं
      browser को धीमा बनाने वाली चीजें ज्यादातर ads, trackers और फालतू junk हैं जो sites पर बोझ डालते हैं, और उसे ठीक करने के लिए Google का कोई आविष्कार नहीं बल्कि uBlock Origin इस्तेमाल होता है। आजकल Google web standards में जो चीजें ठूंसता है, वे आम developers के लिए नहीं बल्कि और ads डालने या datacenter cost में 0.1% बचाने के लिए लगती हैं
    • बहुत पहले से जब मैं कहता था कि non-graphical web use, जैसे तेज और non-interactive information lookup के लिए HTTP/1.1 pipelining HTTP/2 से ज्यादा संतोषजनक था, तो HN पर downvotes और ताने भरे जवाब मिलते थे
      HTTP/2 ऐसा लगता है जैसे एक कंपनी अपने फायदे के हिसाब से public resource यानी www access को लगातार control करने की कोशिश कर रही हो। Chrome इस्तेमाल करने पर आप HTTP/2 आजमाते हैं, और वही कंपनी search engine, hardware, browser, और अब network protocol तक control करती है। HTTP/2 को असल में HTTP/Chrome मान सकते हैं
    • कृपया समझिए कि उन लोगों को सचमुच सालाना promotion material चाहिए था
    • बहुत जल्दी सही होना, गलत होने जैसा ही है

  • HTTP/2 Push क्यों असफल हुआ, इसके लिए दिए गए explanations मुझे कभी convincing नहीं लगे। Google आमतौर पर Jake Archibald के लेख की ओर इशारा करता है, लेकिन वह लेख protocol खुद क्यों नहीं चल सकता, इसकी बजाय browser implementation कितनी खराब थी, इसकी सूची जैसा ज्यादा लगता है
    browsers पहले से preload links support करते हैं, और उसे Push header जैसा ही काम करना चाहिए। caching या authentication headers जैसी 2017 की implementation difficulties में भी सवाल है कि क्या existing preload handling code reuse नहीं किया जा सकता था
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • Preload header को HTTP/2 Push के “असल में वही” नहीं माना जा सकता। नतीजा मिलता-जुलता हो सकता है, लेकिन काम करने का तरीका अलग है, और “Preload” शब्द इस्तेमाल करने जैसी बहुत superficial बात को छोड़ दें तो वे काफी अलग हैं
      HTTP/2 Push में server client को जिन resources की जरूरत होगी ऐसा मानता है, उन्हें पहले से push करके एक round trip कम करता है; इसका लक्ष्य DOM→render pipeline से अलग resources भेजकर latency घटाना है। Preload header में server body के साथ parallel load किए जाने वाले resources बताता है, ताकि parsing या JS evaluation से पहले उन्हें fetch किया जा सके। 103 Early Hints response generation खत्म होने से पहले, body के first byte से पहले Preload hints भेजता है ताकि fetching step और पहले शुरू हो जाए
      मुख्य फर्क server-driven बनाम client-driven, body के साथ बनाम first byte से पहले में है। HTTP/2 Push अपने लक्ष्य हासिल करने में कमजोर क्यों है, इसका सबसे सरल कारण cache है। browser उन resources को request नहीं करता जो उसके पास पहले से हैं, लेकिन server नहीं जानता कि client cache में क्या है। Push में बेकार resources भेजने का जोखिम बड़ा है, जबकि 103/Preload गलत भी हो तो सिर्फ बेकार headers के कुछ bytes waste होते हैं, इसलिए implementation आसान और cost कम है
    • Push specification की मेरी समझ specification जितनी ही जंग खा चुकी थी। मैं यह भूल गया था कि server client को जिनकी जरूरत होने का अनुमान लगाता है, वह पूरा content सचमुच push करता है, और मैंने गलती से सोचा था कि preload link की तरह dependency imply करने वाला केवल header request में शामिल होता है
    • security के लिहाज से pushed resources को page द्वारा ले लिए जाने तक special case की तरह handle करना पड़ता है, और उनमें से एक के लिए अलग cache चाहिए
    • Push हटाने का बहाना खास तौर पर हास्यास्पद है, क्योंकि developers को शुरुआत में ही Push का सही इस्तेमाल करने का मौका बहुत कम मिला। वे incoming Push देख भी नहीं सकते थे, न ही उस पर react कर सकते थे
      https://github.com/whatwg/fetch/issues/51
      content delivery वाले use case में भी, जिस पर सबका ध्यान था, लगता है अभी बहुत अवसर बाकी थे। सार्वजनिक रूप से दिखने वाली कोशिशें भी ज्यादा नहीं थीं, और क्या Push करना चाहिए यह experiment करने के लिए libraries या starting points तक पहुंच बहुत कम लोगों के पास थी

  • HTTP/3 0-RTT startup से कुछ speed वापस मिल सकती है, और 103 Early Hints से browser assets को जल्दी prefetch कर सकता है। इस combination का फायदा यह भी है कि यह HTTP/1 के साथ semantically backward compatible है। reverse proxies या load balancers में भी इसे handle करना आसान है

  • HTTP/2 Push आखिरकार गायब होता देखकर थोड़ा अफसोस है। idea साफ-सुथरा था, लेकिन framework adoption कमजोर रहा, और यह ऐसा feature था जिसे ज्यादा attention मिलनी चाहिए थी
    .NET side ने आखिर तक इसे ship नहीं किया, और nginx में basic implementation जैसा कुछ था। cache digest न होना भी लगातार अड़चन बना रहा। Chrome ने इसे हटाने के कारणों में कुछ हद तक “वैसे भी किसी को पता नहीं चलेगा” जैसा तर्क दिया, और शायद NAT में हमेशा शानदार चलने वाले UDP पर सब कुछ redesign करना ज्यादा जरूरी था

    • UDP और NAT से मुझे कभी समस्या नहीं हुई, लेकिन अगर यह लोगों को परेशान करके IPv6 migration को बढ़ावा देता है, तो मैं चुपचाप मुस्कुराऊंगा

  • HTTP/2 standardize होने से पहले Mike Belshe से बात करते समय भी, पहले से माहौल ऐसा था कि इस feature को H2 से हटाया जाए, क्योंकि benefits हासिल करना कठिन था और problems व pitfalls बहुत थे
    सबसे बड़ी समस्याओं में से एक excessive Push थी—browser cache में पहले से मौजूद चीजें भेजना, या बहुत सारा non-important content भेज देना। मैंने सचमुच ऐसे बहुत खराब cases भी देखे जहां Push की वजह से page load और धीमा हो गया। browser local cache में क्या है, यह server को बताने वाले proposals भी थे, लेकिन वे कई समस्याओं से टकराए। HTTP Early Hints और Resource Hints ने H2 Push की जरूरत को काफी हद तक खत्म कर दिया, और वे implement करने में कहीं आसान हैं, unnecessary fetching से बचते हैं और समझने में भी आसान हैं

  • “वेब सर्वर और वेबसाइट Push का इस्तेमाल करते हुए अगर Firefox में टेस्ट नहीं करते, तो साइट सिर्फ Firefox में रुक सकती है” — ऐसी व्याख्या भी संभव है, लेकिन दूसरी व्याख्याएँ भी संभव हैं
    दूसरे browsers HTTP/2 Push को reject करके चुपचाप ignore कर देते हैं, जबकि Firefox कुछ boundary conditions में बुरी तरह गिर जाता है। मसलन, बात यह है कि “लगता है Firefox header name में uppercase letter मिलने पर connection reset कर देता है”

    • वह व्याख्या ठीक से मेल नहीं खाती। दूसरे browsers ने specification implement नहीं किया है, और Firefox ने specification implement किया है। specification इस violation को कैसे handle करना चाहिए, इस बारे में बहुत स्पष्ट है, और ऐसे web server और website implementations ही broken हैं। अगर specification-compliant client से test किया होता, तो पता चल जाता कि वे टूटे हुए हैं
    • लेख में साफ कहा गया है। Firefox ने HTTP/2 Push को इसलिए support करना जारी रखा क्योंकि हाल तक support cost बड़ी नहीं थी, लेकिन पिछले कुछ महीनों में HTTP/2 Push के जरिए सिर्फ Firefox को प्रभावित करने वाले web compatibility bugs हुए
      यह लेख ठीक उसी कदम को समझाता दिखता है—दूसरे browsers की तरह H2 Push को reject करके चुपचाप ignore करना—और ऐसा नहीं लगता कि कुछ छिपाया जा रहा है
    • उल्टा भी कभी भी हो सकता था। कोई नई specification सिर्फ एक browser में implement हो, और आम तौर पर Chrome उसे पहले अधूरे तरीके से ship कर देता है, फिर server उसे गलत तरह से implement कर दे और वही समस्या पैदा हो जाए—ऐसा ही मामला

  • उत्सुकता है कि Push को ज्यादा व्यापक रूप से अपनाया क्यों नहीं गया। बड़ी कमियों के बावजूद, HTTP/2 को game-changing बनाने वाली बड़ी वजहों में से यह एक माना गया था
    पता नहीं वजह browser support की कमी थी, या यह CDN के साथ ठीक से fit नहीं बैठता था

    • Server Push बड़े पैमाने पर deploy नहीं हुआ क्योंकि यह नुकसानदेह हो सकता है। server ऐसे assets push करता है जिनकी client को जरूरत पड़ सकती है, लेकिन वे assets client cache में पहले से भी हो सकते हैं
      दूसरे मामले में, खासकर mobile पर, यह नुकसानदेह बोझ बन जाता है। server कभी भी बिल्कुल सही नहीं जान सकता कि client को वह asset सच में चाहिए या नहीं। Early Hints शायद बेहतर है; server जरूरत वाले assets जल्दी बता दे, तो client तय कर सकता है कि उन्हें fetch करना है या वे पहले से मौजूद हैं
    • इस्तेमाल पर विचार किया था, फिर विचार बदल दिया। जब Index.html request आती है, तो आम तौर पर आप script.js और style.css push करना चाहेंगे, लेकिन ऐसा करने पर आप सैकड़ों kbit भेज चुके होंगे
      अगर user फिर से index.html request करे, तो क्या सब कुछ फिर से भेजना चाहिए? resources के user cache में पहले से होने की संभावना ज्यादा है। अगर नहीं भेजना, तो कैसे पता चले कि क्या भेजना है? cache में क्या है और क्या नहीं, यह सिर्फ browser जानता है। आखिर में विकल्प यही बचता है: पहली visit तेज करें लेकिन repeat visits में bandwidth waste करें, या पहली visit धीमी रखें और repeat visits तेज करें
    • यह game-changing feature हो सकता था, लेकिन वह Google/Amazon/Meta scale या उससे थोड़ा छोटी companies के लिए था
      बाकी ज्यादातर लोगों के लिए यह भारी complexity increase था, और असल में इसे ignore कर दिया गया
    • Chrome ने जब Push support बंद करने का फैसला किया था, तब जारी की गई ज्यादा विस्तृत analysis देखना मददगार हो सकता है
      https://developer.chrome.com/blog/removing-push/
    • लगता है इसे पर्याप्त समय नहीं दिया गया। HTTP/2 RFC 2015 में final हुआ, तभी HTTP/2 support वाला पहला Apache release आया, और 2017 में भी Server Push handle करने के तरीके में browsers के बीच inconsistencies थीं
      Wikipedia के हिसाब से nginx में Push support करीब 2018 में आया लगता है। ऐसे बदलावों को stable distribution versions और default settings तक नीचे आने में समय चाहिए। मैंने अपने Apache server पर पहली बार HTTP/2 2020 में ही enable किया था, और 2024 में भी ऐसे application servers होने की संभावना है जो इसे सीधे support नहीं करते

  • … Firefox में कह रहा हूँ

    • लगता है बाकी जगहों से तो यह पहले ही सब हटा दिया गया है

  • संबंधित लेख लगते हैं। और भी होंगे?
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - अगस्त 2022, 201 टिप्पणियाँ
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - जुलाई 2022, 2 टिप्पणियाँ
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - दिसंबर 2020, 168 टिप्पणियाँ
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - नवंबर 2020, 133 टिप्पणियाँ
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - सितंबर 2020, 2 टिप्पणियाँ
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - जनवरी 2020, 71 टिप्पणियाँ
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - अक्टूबर 2018, 16 टिप्पणियाँ
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - फरवरी 2018, 63 टिप्पणियाँ
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - जुलाई 2017, 23 टिप्पणियाँ
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - मई 2017, 20 टिप्पणियाँ
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - अप्रैल 2017, 59 टिप्पणियाँ
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - मार्च 2017, 2 टिप्पणियाँ
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - फरवरी 2017, 9 टिप्पणियाँ
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - अगस्त 2016, 6 टिप्पणियाँ
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - अगस्त 2016, 25 टिप्पणियाँ
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - अगस्त 2016, 2 टिप्पणियाँ
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - फरवरी 2016, 13 टिप्पणियाँ

  • कोई हैरानी नहीं। किसी खास उद्देश्य के लिए बने मौजूदा protocol के ऊपर, उसके मूल design goals से लगभग असंबंधित feature जोड़ दें तो आम तौर पर यही होता है
    ज़्यादातर मामलों में low-level protocol से शुरू करके सीधे use case के हिसाब से ढालना बेहतर होता है, और इस लिहाज़ से मुझे लगता है कि WebSockets ने दो-तरफा communication की समस्या पहले ही elegant तरीके से हल कर दी है। गहरी file/script hierarchy load करते समय latency घटाने के लिए rel="preload" या rel="modulepreload" tags शानदार और simple संरचना हैं

    • HTTP/2 Push शायद latency घटाने वाले preload links वाले ठीक उसी use case में फिट बैठता
      मुद्दा यह था कि server पहले से load किए जाने वाले content को headers के रूप में भेजे, ताकि link tag के भेजे या parse किए जाने से पहले ही उसे preload किया जा सके। streaming support करने वाले pages के लिए यह कम उपयोगी होगा, लेकिन जहाँ request पूरी HTML page के server-side render होने तक रुकी रहती है, वहाँ इसका noticeable फायदा हो सकता था
    • HTTP/2 एक नया low-level protocol था, और HTTP Push शुरू से ही दो-तरफा communication से जुड़ा feature नहीं था
    • क्या HTTP भी दो-तरफा communication नहीं है?