HTTP हेडर पार्सर
रॉ HTTP रिक्वेस्ट या रिस्पॉन्स हेडर को संरचित तालिका में पार्स करें। स्टेटस लाइन, हेडर, कुकीज़ और कंटेंट-टाइप जानकारी तुरंत निकालें।
| नाम | मान |
|---|
Invalid Headers
HTTP हेडर पार्सर का उपयोग कैसे करें
हेडर पेस्ट करें
ब्राउज़र DevTools (Network टैब) या किसी भी स्रोत से रॉ HTTP हेडर कॉपी करें और इनपुट क्षेत्र में पेस्ट करें।
स्वतः पार्स
हेडर तुरंत संरचित तालिका में पार्स हो जाते हैं, यह स्वतः पहचान लिया जाता है कि इनपुट रिक्वेस्ट है या रिस्पॉन्स।
विवरण देखें
स्टेटस लाइन, अलग-अलग हेडर, निकाली गई कुकीज़ और कंटेंट-टाइप विश्लेषण की समीक्षा करें।
HTTP हेडर क्या हैं?
HTTP हेडर की-वैल्यू जोड़े हैं जो HTTP रिक्वेस्ट और रिस्पॉन्स में क्लाइंट और सर्वर के बीच भेजे जाते हैं। वे रिक्वेस्ट या रिस्पॉन्स के बारे में मेटाडेटा ले जाते हैं, जैसे कंटेंट टाइप, कैशिंग नियम, प्रमाणीकरण टोकन और कुकी जानकारी। वेब एप्लिकेशन डीबग करने, प्रदर्शन अनुकूलित करने और सुरक्षा सुनिश्चित करने के लिए हेडर समझना आवश्यक है।
रिक्वेस्ट हेडर
क्लाइंट द्वारा सर्वर को भेजे जाते हैं, जिनमें Host, User-Agent, Accept, Authorization और Cookie हेडर शामिल हैं।
रिस्पॉन्स हेडर
सर्वर द्वारा क्लाइंट को वापस भेजे जाते हैं, जिनमें Content-Type, Set-Cookie, Cache-Control और X-Request-Id हेडर शामिल हैं।
सुरक्षा हेडर
Content-Security-Policy, Strict-Transport-Security और X-Frame-Options जैसे हेडर जो सुरक्षा बढ़ाते हैं।
अक्सर पूछे जाने वाले प्रश्न
हाँ। पार्सर पहली पंक्ति के आधार पर स्वतः पहचानता है कि इनपुट HTTP रिक्वेस्ट है या रिस्पॉन्स, और उसी के अनुसार पार्स करता है। रिक्वेस्ट लाइन HTTP मेथड (GET, POST आदि) से शुरू होती है, जबकि रिस्पॉन्स लाइन HTTP/version से।
हाँ। Set-Cookie हेडर अलग-अलग कुकीज़ में पार्स होकर नाम, मान और सभी फ़्लैग दिखाते हैं जैसे HttpOnly, Secure, SameSite, Path, Domain और Max-Age।
मानक HTTP/1.1 और HTTP/2 हेडर प्रारूप, प्रति पंक्ति एक हेडर "Name: Value" रूप में। आप ब्राउज़र डेवलपर टूल से सीधे हेडर कॉपी कर सकते हैं।
रिक्वेस्ट में आमतौर पर host, user-agent, accept, accept-encoding और cookie होते हैं; रिस्पॉन्स content-type, content-length, cache-control, set-cookie और date के साथ जवाब देता है। API ट्रैफ़िक जाते समय authorization और content-type: application/json जोड़ता है, और लौटते समय rate-limit हेडर। RFC 9110 (HTTP semantics, 2022) वह आधुनिक संदर्भ है जो इन सबको परिभाषित करता है।
रिक्वेस्ट हेडर (host, authorization, accept-*) बताते हैं कि क्लाइंट क्या चाहता है; रिस्पॉन्स हेडर (location, set-cookie, retry-after) बताते हैं क्या वापस आया। कुछ फ़ील्ड दोनों दिशाओं में आते हैं (cache-control, content-type), और कुछ संदेश सामग्री के बजाय कनेक्शन को नियंत्रित करते हैं (connection: keep-alive)। यह पार्सर चिह्नित करता है कि प्रत्येक हेडर किस पक्ष का है।
RFC 9110 के अनुसार, दोहराए गए अधिकांश फ़ील्ड एक कॉमा-सेपरेटेड सूची में मिल जाते हैं - दो cache-control लाइनें और no-cache, no-store लिखी एक लाइन समतुल्य हैं। Set-Cookie प्रलेखित अपवाद है: यह कभी कॉमा-मर्ज नहीं हो सकता क्योंकि Expires तारीखों में कॉमा होते हैं, इसलिए प्रॉक्सियों को हर Set-Cookie अलग से फ़ॉरवर्ड करना चाहिए। वह अपवाद प्रॉक्सी बग का क्लासिक स्रोत है।
फ़ील्ड नाम लोअरकेस हो गए और HPACK या QPACK-संपीड़ित बाइनरी फ़्रेम के रूप में यात्रा करते हैं; प्रत्येक रिक्वेस्ट अपना स्ट्रीम खोलता है, और Host जैसे प्रति-कनेक्शन हेडर :method, :scheme और :path के साथ :authority स्यूडो-हेडर से बदले गए। शब्दार्थ के स्तर पर फ़ील्ड अब भी RFC 9110 का पालन करते हैं - वायर फ़ॉर्मैट बदला, शब्दावली नहीं।
फ़ील्ड नाम और कोलन के बीच व्हाइटस्पेस (Header : value) - HTTP/1.1 पार्सिंग और HTTP/2 विनिर्देश दोनों रिक्वेस्ट स्मग्लिंग रोकने के लिए इसे अस्वीकार करते हैं। और भी अमान्य: फ़ील्ड नाम के अंदर स्पेस या non-ASCII बाइट, मानों में कंट्रोल कैरेक्टर, और obs-fold (इंडेंटेड लाइन से जारी हेडर), जिसे RFC 9110 अप्रचलित चिह्नित करता है - इसे एकल लाइन या लिस्ट मान से बदलें।
संबंधित टूल्स
प्रामाणिक संदर्भ
इस टूल के पीछे के मूल स्रोत — दूसरे हाथ के सार नहीं, बल्कि आधिकारिक स्टैंडर्ड और स्पेसिफिकेशन।