HAR फ़ाइल क्या है और क्या इसे शेयर करना सुरक्षित है?
HAR (HTTP Archive) फ़ाइल वह JSON log है जो ब्राउज़र के developer tools Network पैनल से export करते हैं: हर request अपने URL, method, headers, cookies, timings, sizes और, अगर बाहर न रखा जाए तो, response content के साथ। यह ठीक-ठीक दिखाती है कि ब्राउज़र ने क्या भेजा और क्या पाया, इसीलिए support टीमें इसे माँगती हैं — और इसीलिए यह संवेदनशील है: session cookies, Authorization headers और tokens plain text में दर्ज होते हैं, और valid session cookie से कोई user की तरह काम कर सकता है। HAR अपने हाथ से जाने से पहले इन्हें हटाएँ या redact करें।
HAR फ़ाइल एनालाइज़र कैसे इस्तेमाल करें
- HAR export करें: ब्राउज़र के developer tools में Network टैब खोलें, Preserve log चुनें, समस्या दोहराएँ, फिर Save all as HAR चुनें।
- .har फ़ाइल चुनें (या उसका JSON पेस्ट करें) — यह आपके ब्राउज़र में ही रहती है।
- अगर default (1,000 ms और 500 KB) पेज के लिए ठीक नहीं हैं तो slow-request और large-response threshold बदलें।
- विश्लेषण करें दबाएँ और पहले Checks तालिका पढ़ें: FAIL पंक्तियाँ errors और secrets हैं, WARN पंक्तियाँ performance से जुड़ी बातें।
- HAR किसी को भेजने से पहले sanitized कॉपी चुनें, दोबारा चलाएँ, कॉपी जाँचें और मूल फ़ाइल की जगह वही शेयर करें।
HAR फ़ाइल एनालाइज़र की खूबियाँ
- Chrome, Edge, Firefox और Safari से export की गई HAR 1.2 फ़ाइलें पढ़ता है, 30 MB और 20,000 requests तक
- उन requests को दिखाता है जिन्हें कोई response नहीं मिला (blocked, cancelled, network error) और हर 4xx व 5xx response, ब्राउज़र के अपने error text के साथ
- आपकी threshold से धीमी requests खोजता है और सबसे लंबे phase का नाम बताता है — server का इंतज़ार (TTFB), download, TLS, connection, DNS या queueing
- सबसे बड़े responses, redirects और redirect chains, session में दोहराई गई एक जैसी requests, बिना compression के text responses और https:// पेज से http:// requests दिखाता है
- Requests को host (first party या third party) और resource type के अनुसार समूहों में रखता है, transfer हुए bytes के साथ
- फ़ाइल की हर cookie, credential header, token और secret जैसे दिखने वाले parameter को masked value के साथ सूचीबद्ध करता है, और ऐसी sanitized HAR लिखता है जिसमें ये values [REDACTED] से बदली गई हों, चाहें तो bodies हटाकर
HAR फ़ाइल एनालाइज़र का उदाहरण
एक shop पेज जो धीरे लोड होता है और जिसका "Recommended" ब्लॉक ख़ाली दिखता है
इनपुट:
उदाहरण HAR (shop.example.com के लिए काल्पनिक डेटा): 9 requests, threshold 1,000 ms / 500 KB, bodies रखते हुए sanitized कॉपीआउटपुट:
FAIL बिना response वाली requests: 1 (analytics.example.org — net::ERR_BLOCKED_BY_CLIENT) · FAIL server errors: 1 (POST /api/recommendations 503, 2.31 s, waiting (TTFB) 2.30 s) · WARN client errors: 1 (hero.webp 404) · WARN धीमी: 2 · WARN redirect chain: http://shop.example.com/ → https://shop.example.com/ → https://www.shop.example.com/ · WARN दोहराई गई: GET /api/cart दो बार · FAIL secrets: 5 (session cookie, Authorization header, URL में access_token) · sanitized कॉपी: 7 values बदली गईंHAR फ़ाइल एनालाइज़र कब इस्तेमाल करें
- Support ticket के साथ ग्राहक की भेजी HAR पढ़कर सेकंडों में फ़ेल होने वाली request ढूँढना
- धीमे पेज को सबूत के साथ समझाना: कौन-सी request धीमी थी और कारण server था या download
- Performance testing के दौरान capture में redirect chains, दोहराई गई API calls और बिना compression वाले assets जाँचना
- Bug report में लगाने या vendor को भेजने से पहले HAR से session cookies और tokens हटाना
HAR फ़ाइल एनालाइज़र के बारे में अक्सर पूछे जाने वाले सवाल
HAR फ़ाइल क्या है?
HAR (HTTP Archive) फ़ाइल उन सभी requests का JSON log है जो ब्राउज़र ने तब भेजीं जब उसके developer tools का Network टैब रिकॉर्ड कर रहा था: URLs, methods, headers, cookies, timings, sizes और, अगर आप बाहर न रखें तो, response content भी। Support टीमें इसे इसलिए माँगती हैं क्योंकि यह ठीक-ठीक दिखाती है कि ब्राउज़र ने क्या भेजा और क्या पाया।
HAR फ़ाइल कैसे export करें?
Chrome या Edge में DevTools (F12) खोलें, Network टैब चुनें, Preserve log चुनें, समस्या दोहराएँ, फिर request सूची पर right-click करके Save all as HAR चुनें (या download तीर इस्तेमाल करें)। Firefox में Network टैब के gear मेन्यू → Save All As HAR; Safari में Develop मेन्यू चालू करके Network टैब में Export चुनें।
क्या HAR फ़ाइल शेयर करना सुरक्षित है?
जैसी है वैसी नहीं। HAR session cookies, Authorization headers, access tokens और password जैसे form fields को plain text में रिकॉर्ड करती है, और जिसके पास valid session cookie हो वह आपकी तरह काम कर सकता है। "Secrets found" सूची देखें, sanitized कॉपी बनाएँ, उसे जाँचें, और सिर्फ़ उन्हीं से शेयर करें जिन्हें उसकी ज़रूरत है।
Sanitized कॉपी क्या हटाती है?
यह credential headers (Authorization, Cookie, Set-Cookie, API-key और CSRF headers), सभी cookies, उन query, form और JSON fields की values जिनके नाम secret जैसे दिखते हैं (token, password, session, key, code…), और फ़ाइल में कहीं भी JWT और Bearer tokens को [REDACTED] से बदल देती है। चाहें तो यह हर request और response body भी हटा देती है। पहचान नाम और pattern पर आधारित है, इसलिए शेयर करने से पहले कॉपी जाँचें।
क्या मेरी HAR फ़ाइल अपलोड होती है?
नहीं। फ़ाइल आपके ब्राउज़र में पढ़ी और विश्लेषित की जाती है; Mutqan या किसी और को कुछ नहीं भेजा जाता। नतीजे कॉपी करने के लिए अकाउंट नहीं चाहिए; रिपोर्ट या sanitized फ़ाइल डाउनलोड करने पर मुफ़्त अकाउंट में साइन इन करने को कहा जाता है।
तकनीकी नोट्स
Sizes के लिए Chrome का _transferSize इस्तेमाल होता है जब मौजूद हो (compression के बाद network पर गए bytes), वरना headersSize + bodySize; फ़ाइल में −1 का मतलब "पता नहीं" है और उसे शून्य गिना जाता है। Decoded size response.content.size है। Status 0 और _error field वाली request वह है जिसे ब्राउज़र ने कभी पूरा नहीं किया।
धीमे phase का पता timings object से चलता है: blocked, dns, connect (TLS का समय, ssl, connect का हिस्सा है और अलग दिखाया जाता है), send, wait (पहले byte तक का समय) और receive। लंबा wait server या उसके पीछे की dependency की ओर इशारा करता है; लंबा receive response के आकार या connection की ओर।
Redirect chains हर 3xx response के redirectURL (या Location header) को request URL के सापेक्ष resolve करके बनाई जाती हैं। दोहराई गई requests यानी एक ही method और URL एक से ज़्यादा बार; कुछ जान-बूझकर होती हैं (polling, retries), इसलिए उन्हें WARN दिखाया जाता है, FAIL नहीं।
Secrets header के नामों (Authorization, Cookie, Set-Cookie, X-API-Key, CSRF headers और अन्य), token, secret, password, session, key, code, signature जैसे शब्दों वाले parameter और JSON field के नामों, और URLs, headers व bodies में कहीं भी JWT और Bearer patterns से पहचाने जाते हैं।
सीमाएँ और कार्यप्रणाली
विश्लेषण उतना ही पूरा है जितना capture: रिकॉर्डिंग शुरू होने से पहले की requests, या Network टैब के filter से छिपी requests, फ़ाइल में नहीं होतीं।
Timings उस ब्राउज़र से आती हैं जिसने फ़ाइल रिकॉर्ड की, और उस समय की उस मशीन व network को दिखाती हैं; एक capture एक नमूना है, benchmark नहीं।
Sanitize करना नामों और token patterns पर आधारित है। किसी असामान्य नाम से रखा secret, HTML पेज के अंदर का token (छिपा form field), multipart या XML body, या response body में निजी डेटा बच सकता है — शक हो तो bodies हटाएँ, और शेयर करने से पहले कॉपी हमेशा जाँचें।
First-party hosts को उनके आख़िरी दो labels से समूहित किया जाता है (example.com.sa जैसे नामों के लिए तीन); यह एक अनुमानित नियम है, Public Suffix List नहीं।
सुरक्षा और गोपनीयता
HAR ब्राउज़र की File API से पढ़ी जाती है और इसी पेज में विश्लेषित होती है; Mutqan इसे कभी अपलोड, log या store नहीं करता।
Secret values masked दिखाई जाती हैं (पहले और आख़िरी दो अक्षर और लंबाई), और तालिकाओं व रिपोर्ट के URLs में secret जैसी query values बदल दी जाती हैं, ताकि तालिका कॉपी करने पर secrets कॉपी न हों।
शेयर की गई HAR वापस नहीं ली जा सकती: अगर बिना sanitize की HAR भेजी जा चुकी है, तो प्रभावित sessions से sign out करें या उसमें मौजूद tokens बदलें।
संदर्भ
- What are browser developer tools? — MDNब्राउज़र में बने developer tools का परिचय — inspector, JavaScript console और debugger — टेस्ट करते समय पेज की जाँच के लिए।
- RFC 9110: HTTP SemanticsHTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
- OWASP Cheat Sheet Series: Session Managementसेशन आइडेंटिफ़ायर की एंट्रॉपी, कुकी एट्रिब्यूट, एक्सपायरी, लॉगिन के बाद नवीनीकरण और लॉगआउट हैंडलिंग।