Gwtar: स्थिर और कुशल single-file HTML फ़ॉर्मैट

 (gwern.net)
1 पॉइंट द्वारा GN⁺ 2026-02-17 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह एक single HTML archive file format है जिसे वेब ब्राउज़र lazy-loading के साथ कुशलतापूर्वक लोड कर सकते हैं; यह सभी assets को शामिल करते हुए भी स्थिरता, single-file संरचना और दक्षता तीनों को साथ में हासिल करता है
  • HTML और JavaScript header के बाद tarball रूप में मूल HTML और assets को जोड़ा जाता है, और JS HTTP Range requests के ज़रिए केवल ज़रूरी हिस्से लोड करता है
  • मौजूदा SingleFile या MHTML जैसे फ़ॉर्मैट स्थिरता और single-file गुण तो देते हैं, लेकिन दक्षता में कमी रहती है; Gwtar इस समस्या को हल करता है
  • सर्वर-साइड अतिरिक्त सेटअप के बिना यह सिर्फ standard browser features पर काम करता है, और Cloudflare जैसे कुछ environments में MIME type x-gwtar का उपयोग किया जाता है
  • बड़े HTML पेजों की दीर्घकालिक संरक्षितता और accessibility दोनों सुनिश्चित करने के कारण यह long-term web archiving और reproducible research materials के संरक्षण में उपयोगी है

Gwtar का अवलोकन

  • Gwtar एक नया polyglot archive format है जो single HTML file से बना होता है, और ब्राउज़र HTTP Range requests के माध्यम से केवल ज़रूरी हिस्से लोड करता है
    • इसका उपयोग Gwern.net के बड़े HTML archives उपलब्ध कराने में किया जाता है
  • HTML header का JS पूरी फ़ाइल का डाउनलोड रोक देता है और ज़रूरी assets को partial requests (range request) के ज़रिए लाता है
  • परिणामस्वरूप सर्वर केवल एक single HTML file देता है, लेकिन उपयोगकर्ता सिर्फ आवश्यक assets ही डाउनलोड करता है
  • सारी functionality standard browser features से लागू की गई है, जिससे future compatibility सुनिश्चित होती है

HTML archive की त्रि-दुविधा

  • HTML archives में स्थिरता, single-file होना, और दक्षता—इनमें से सामान्यतः केवल दो ही गुण एक साथ मिल पाते थे
    • उदाहरण: SingleFile स्थिर और single-file है, लेकिन अक्षम है; WARC स्थिर और कुशल है, लेकिन single-file नहीं है
  • SingleFile से बने snapshots पूरी तरह स्थिर पेज तो देते हैं, लेकिन सभी assets को Base64 में inline करने के कारण फ़ाइल का आकार सैकड़ों MB तक बढ़ जाता है
  • उपयोगकर्ता पेज का केवल एक हिस्सा देखे तब भी पूरी फ़ाइल डाउनलोड करनी पड़ती है, जिससे अक्षम्यता पैदा होती है
  • Gwern.net ने इसे हल करने के लिए deconstruct_singlefile.php से assets अलग किए, लेकिन इससे single-file गुण खो गया

Gwtar का तकनीकी दृष्टिकोण

  • HTTP Range requests का उपयोग कर फ़ाइल के केवल कुछ हिस्सों को चुनकर डाउनलोड किया जा सकता है
  • HTML + JS header के बाद tarball जोड़ने वाली concatenated archive structure अपनाई गई है
  • JS का window.stop() कमांड header के बाद डाउनलोड रोकता है और फिर केवल ज़रूरी assets मंगाए जाते हैं
  • ब्राउज़र इसे सामान्य HTML की तरह render करता है, और JS asset requests को intercept करके उन्हें Range requests में बदल देता है

निर्माण और implementation

  • PHP script deconstruct_singlefile.php के ज़रिए SingleFile HTML को Gwtar में बदला जा सकता है
    • JPG/PNG/GIF recompression और PAR2 FEC (forward error correction) data जोड़ने का समर्थन भी है
  • JS चलने के बाद ब्राउज़र सिर्फ ज़रूरी assets को Range requests से लाता है, और JS disabled होने पर पूरी फ़ाइल डाउनलोड करने पर fallback हो जाता है
  • यह standard-based है, इसलिए server settings या अतिरिक्त software की आवश्यकता नहीं होती, और single file से वापस multi-file HTML में restore भी किया जा सकता है

प्रदर्शन और compatibility

  • यदि Range requests समर्थित न हों, तो पूरी फ़ाइल डाउनलोड होती है, लेकिन gzip/Brotli compression से गति की भरपाई की जा सकती है
  • Cloudflare text/html responses से Range header हटा देता है, इसलिए Gwern.net इसे bypass करने के लिए MIME type x-gwtar सेट करता है
  • लोकल में फ़ाइल देखना संभव नहीं है :
    • यह SingleFileZ की तरह ही है, क्योंकि browser security policies (जैसे CORS) JS requests को ब्लॉक कर देती हैं
    • इसे खेदजनक लेकिन स्वीकार्य trade-off माना गया है, और local browsing को JS-निर्भर न रहने वाली फ़ाइल में बदलकर संभाला जा सकता है

विस्तारित सुविधाएँ

  • Gwtar फ़ाइल के अंत में अतिरिक्त binary data (जैसे FEC, signatures, metadata) जोड़ा जा सकता है
  • PAR2 की मदद से फ़ाइल के कुछ हिस्से खराब होने पर recovery संभव है
  • GPG signature को HTML comment के रूप में डालकर integrity verification की जा सकती है
  • भविष्य के versions में asset hash verification, automatic prefetch, built-in compression, multi-page support जैसी सुविधाएँ नियोजित हैं

उपयोग की संभावनाएँ

  • बड़े HTML pages या research datasets (जैसे SQLite3) को शामिल करने वाले reproducible scientific research के लिए यह उपयुक्त है
  • ब्राउज़र में सीधे database को Range requests के माध्यम से लोड करके analysis किया जा सकता है
  • इसे web archiving format के रूप में प्रस्तावित किया गया है, जो long-term preservation और accessibility दोनों सुनिश्चित करता है

लाइसेंस और आगे का विकास

  • Gwtar के documents और code को CC-0 public domain के रूप में जारी किया गया है
  • भविष्य के version (v2) में FEC को अनिवार्य बनाना, built-in compression, multi-document support, और deduplication में सुधार जैसे बिंदुओं पर विचार किया जा रहा है

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

1 टिप्पणियां

 
GN⁺ 2026-02-17
Hacker News टिप्पणियाँ

  • आज पहली बार window.stop() के बारे में पता चला
    यह फ़ंक्शन ब्राउज़र को आगे कोई resource लोड करने से रोकता है
    बड़े ब्राउज़र इसे पहले से 10 साल से ज़्यादा समय से support कर रहे हैं (MDN दस्तावेज़, Can I Use)
    इसका उपयोग उदाहरण इस screenshot में देखा जा सकता है
    अधिक विवरण मेरी blog post में है

    • अगर आप SPA developer हैं, तो यह कहना मुश्किल है कि यह document.write या window.open जैसे API से बेहतर है
      लेकिन server-केंद्रित logic में download या lazy-loading को सीधे implement करना हो, तो यह एक दिलचस्प तरीका हो सकता है
      initialization या redirect script जैसी खास परिस्थितियों को छोड़ दें, तो इसे recommend करना कठिन है
    • सोच रहा हूँ कि क्या यह Claude Artifacts के साथ compatible होगा
      मैं अपने बनाए bundler के ज़रिए files को compressed base64 chunks के रूप में publish करता हूँ, तो यह तरीका काफ़ी मिलता-जुलता है
      अगर यह ऐसे single-file sharing environment में काम करता है, तो लगता है platform इसे block भी कर सकता है
    • मुझे भी यह फीचर पहली बार पता चला
      PHP में भी ऐसा ही __halt_compiler() फीचर है, और मैंने इसका उपयोग file के अंत में documentation या data को बिना comment के जोड़ने के लिए किया है

  • शुरुआत में यह दिलचस्प लगा, लेकिन जब पता चला कि यह format local files से सीधे नहीं खुलता, तो थोड़ा संदेह हुआ
    अगर यह archival format है, तो local access उसके मुख्य use case में से एक होना चाहिए

    • मैं भी यही सोचता हूँ। लगा था कि asm.js की तरह यह browser में built-in capabilities का उपयोग करके नई संभावनाएँ खोलेगा
      लेकिन अगर यह local में सीधे नहीं खुलता, तो इसका फ़ायदा काफ़ी कम हो जाता है (backdoor pilot की अवधारणा देखें)
    • शायद viewer program या एक साधारण static HTML server से इसका समाधान हो सकता है
    • वास्तव में HTML खुद ही एक शानदार single-file format है
      image, CSS, JS सब कुछ data-uri के रूप में inline किया जा सकता है, और fonts भी ऐसे ही
      बल्कि अगर word processor document formats ने HTML का उपयोग किया होता, तो वे शायद ज़्यादा flexible होते
    • python -m http.server जैसे command से local server चलाकर इसे आसानी से हल किया जा सकता है
      Claude command से भी यह संभव है

  • अगर लेखक यह पोस्ट देख रहे हों, तो अच्छा होगा कि archive format में BASE64 screenshot field, description field, और ISO timestamp जोड़े जाएँ
    आगे चलकर अगर एक ही URL के कई versions store किए जा सकें और deduplicated assets की सुविधा हो, तो वह आदर्श होगा

  • समझ नहीं आता कि लेखक ने WARC को नकारात्मक रूप में क्यों देखा
    उल्टा Gwtar ज़्यादा complex और कम flexible लगता है

    • लेकिन WARC ऐसा URL नहीं दे सकता जिसे browser में सीधे क्लिक करके देखा जा सके
    • एक और comment में कहा गया कारण यह था कि WARC/WACZ static और efficient तो हैं, लेकिन उन्हें single file के रूप में सीधे render नहीं किया जा सकता, और इसके लिए WebRecorder जैसी अलग और अपेक्षाकृत complex setup चाहिए

  • जानना चाहता हूँ कि SingleFile की ZIP/HTML polyglot format को “static और single है, लेकिन inefficient” क्यों कहा गया
    Gwtar की तुलना में यह किस तरह inefficient है?

    • यहाँ efficiency से मतलब है ज़रूरत पड़ने पर केवल आवश्यक assets को आंशिक रूप से download कर पाने की क्षमता
      मुख्य बात यह है कि browser request के समय पूरा file लिए बिना, range request के माध्यम से केवल ज़रूरी हिस्से ला सके या नहीं

  • यह सच में शानदार विचार है
    मुझे लगता है कि single-file HTML webapp सॉफ़्टवेयर का सबसे लंबे समय तक टिकने वाला रूप है
    मेरे बनाए उदाहरणों में FuzzyGraph और HyperVault शामिल हैं

  • मैंने भी कुछ ऐसा Service Worker स्तर पर implement करने के बारे में सोचा था
    यानी page को वैसा ही रहने देना, और सभी HTTP requests को intercept करना
    window.stop() की तरह सिर्फ़ HTML का एक हिस्सा लेना और बाकी को asset blob के रूप में संभालना
    अगर Service Worker को ही dataURI के रूप में डाल दिया जाए, तो यह पूरी तरह single file बन सकता है

  • दिलचस्प है, लेकिन समझ नहीं आता कि local file में lazy load की ज़रूरत क्यों होगी
    क्या file इतनी बड़ी होने वाली है? या पहले से बने features को जस का तस रखना है?

    • असल में लक्ष्य local नहीं, बल्कि HTTP server पर मौजूद बड़े files हैं
      network से पूरा file लिए बिना केवल ज़रूरी हिस्से माँगने के लिए range request चाहिए
      बेशक कई files में बाँटना ज़्यादा सामान्य तरीका है, लेकिन कभी-कभी single-file management ज़्यादा सुविधाजनक होता है
      संभव है कि इसका संबंध Gwern के MediaWiki-आधारित site की संरचना से हो

  • मैंने पहले भी कुछ ऐसा बनाया था — Zundler नाम का एक project, जो काफ़ी hacky approach था
    यह local में भी काम करता है, लेकिन शुरुआत में पूरा archive extract करना पड़ता है

    • यह SingleFileZ जैसा single static HTML archive लगता है, लेकिन ऐसा जिसे local में भी आसानी से देखा जा सकता है
      हालांकि यह security restrictions को कैसे bypass करता है, यह जानने की उत्सुकता है
      description में केवल single-origin का उल्लेख है, इसलिए पूरी तरह समझना थोड़ा कठिन है