HTTP हेडर लुकअप

हमारे HTTP हेडर्स लुकअप टूल के साथ एक सामान्य GET अनुरोध के लिए किसी URL द्वारा लौटाए गए सभी HTTP हेडर्स प्राप्त करें।

2 रेटिंग्स में से 5

HTTP हेडर लुकअप एक मुफ़्त टूल है, जो किसी URL पर सामान्य GET अनुरोध भेजकर लौटाए गए सभी HTTP रिस्पॉन्स हेडर प्राप्त करता है।

HTTP रिस्पॉन्स हेडर क्या होते हैं?

HTTP रिस्पॉन्स हेडर मेटाडेटा के छोटे हिस्से होते हैं, जिन्हें वेब सर्वर रिस्पॉन्स बॉडी से पहले भेजता है। रिस्पॉन्स बॉडी कोई HTML पेज, इमेज या JSON दस्तावेज़ हो सकती है। ये हेडर क्लाइंट को बताते हैं कि रिस्पॉन्स को कैसे समझना, कैश करना, रीडायरेक्ट करना या सुरक्षित रखना है।

HTTP/1.x रिस्पॉन्स आम तौर पर HTTP स्टेटस लाइन से शुरू होता है, जिसके बाद हेडर आते हैं। HTTP/2 और HTTP/3 में यही स्टेटस :status स्यूडो-हेडर में दिया जाता है। तकनीकी रूप से HTTP/1.x स्टेटस लाइन हेडर से अलग होती है, लेकिन इसे अक्सर उनके साथ दिखाया जाता है, क्योंकि इससे पता चलता है कि अनुरोध सफल रहा या नहीं। 200 जैसे स्टेटस का अर्थ है कि रिसोर्स लौटा दिया गया, 301 या 302 रीडायरेक्ट दर्शाता है, 404 का अर्थ है कि रिसोर्स नहीं मिला और 500 सर्वर की ओर हुई त्रुटि बताता है।

हेडर मूल सर्वर, रिवर्स प्रॉक्सी या Cloudflare जैसे कंटेंट डिलीवरी नेटवर्क से आ सकते हैं। इन सिस्टम से गुजरते समय कुछ हेडर जोड़े या हटाए जा सकते हैं। इसलिए नतीजा केवल उस ऐप्लिकेशन के बारे में नहीं बताता जिसने पेज बनाया था।

आरेख: सर्वर को भेजा गया अनुरोध HTTP रिस्पॉन्स हेडर लौटाता है

HTTP हेडर कैसे देखें?

जिस URL की जांच करनी है, उसका पूरा पता दर्ज करें। इसमें स्कीम भी शामिल होनी चाहिए, जैसे https://www.example.com/account। HTTP हेडर लुकअप अपने सर्वर से सामान्य GET अनुरोध भेजता है और उस URL से मिले HTTP हेडर दिखाता है।

रिस्पॉन्स हेडर की सटीक तुलना के लिए URL के उन्हीं रूपों का इस्तेमाल करें जिनकी जांच करनी है। http://example.com, https://example.com और https://www.example.com के हेडर अलग हो सकते हैं, क्योंकि हर पते के अपने रीडायरेक्ट, कैशिंग नियम और सर्वर कॉन्फ़िगरेशन हो सकते हैं।

URL का सिंटैक्स भी अनुरोध को प्रभावित करता है:

URL में स्पेस को सीधे वर्ण के रूप में इस्तेमाल नहीं किया जा सकता। आम तौर पर इसे प्रतिशत-एन्कोड करना पड़ता है, और पाथ में प्रायः %20 लिखा जाता है।
? से क्वेरी वाला हिस्सा शुरू होता है। फ़ॉर्म-शैली वाली क्वेरी एन्कोडिंग में & और = का आम तौर पर इस्तेमाल होता है, लेकिन हर क्वेरी स्ट्रिंग में इनकी यही भूमिका नहीं होती।
उच्चारण चिह्नों वाले और गैर-लैटिन डोमेन नामों को IDNA से प्रोसेस करके ASCII A-labels के रूप में दिखाया जाता है, जो आम तौर पर xn-- से शुरू होते हैं। वहीं पाथ के वर्णों को सामान्यतः पहले UTF-8 बाइट्स और फिर प्रतिशत-एन्कोडेड रूप में बदला जाता है।
# से शुरू होने वाले फ़्रैगमेंट को ब्राउज़र संभालता है और उसे HTTP अनुरोध में नहीं भेजा जाता।
URL की अधिकतम लंबाई के लिए कोई सार्वभौमिक सीमा नहीं है। बहुत लंबे URL को सर्वर, प्रॉक्सी या ऐप्लिकेशन अस्वीकार कर सकता है।

digily.link पर HTTP हेडर लुकअप टूल और उसका इनपुट फ़ॉर्म

HTTP हेडर के नतीजे को कैसे समझें?

जिस समस्या की जांच कर रहे हैं, उससे जुड़े हेडर देखें। हेडर के नाम केस-सेंसिटिव नहीं होते, हालांकि उनकी वैल्यू के सिंटैक्स में बड़े और छोटे अक्षरों से अंतर पड़ सकता है।

नतीजे का फ़ील्ड	इससे क्या पता चलता है
Location	रीडायरेक्ट का गंतव्य। यह आम तौर पर 3xx स्टेटस के साथ आता है।
Content-Type	लौटाया गया मीडिया प्रकार, जैसे text/html, application/json या image/png।
Content-Length	रिस्पॉन्स बॉडी का घोषित आकार, बाइट्स में, बशर्ते सर्वर यह जानकारी दे। चंक्ड या डायनेमिक रूप से बनाए गए रिस्पॉन्स में यह नहीं भी हो सकता है।
Cache-Control and Expires	कैशिंग के निर्देश और, उपलब्ध होने पर, रिस्पॉन्स के समाप्त होने का समय।
Age	कैश किए गए रिस्पॉन्स के बनने या आखिरी बार वैलिडेट होने के बाद की गणना की गई आयु, सेकंड में। इसमें अपस्ट्रीम कैश में बीता समय भी शामिल हो सकता है।
ETag and Last-Modified	ऐसे वैलिडेटर जिनसे क्लाइंट जांच सकते हैं कि कैश की गई सामग्री बदली है या नहीं।
Set-Cookie	कुकी स्टोर करने का अनुरोध, जिसमें Secure, HttpOnly और SameSite जैसे एट्रिब्यूट शामिल हो सकते हैं।
Content-Security-Policy	ब्राउज़र के लिए वे नियम जो तय करते हैं कि कोई पेज किन स्क्रिप्ट, स्टाइल, फ़्रेम और दूसरे रिसोर्स को लोड कर सकता है।
Strict-Transport-Security	संगत ब्राउज़र को बताने वाला निर्देश कि तय अवधि तक HTTPS का इस्तेमाल किया जाए।

कुछ दूसरे हेडर किसी खास ऐप्लिकेशन से जुड़े हो सकते हैं। उदाहरण के लिए, Access-Control-Allow-Origin तय करता है कि ब्राउज़र के क्रॉस-ओरिजिन अनुरोधों के जरिए कौन से ओरिजिन किसी रिस्पॉन्स को पढ़ सकते हैं। Server हेडर में किसी सॉफ़्टवेयर या प्रॉक्सी का नाम हो सकता है, लेकिन इसे वास्तविक प्लेटफ़ॉर्म का पक्का प्रमाण नहीं माना जा सकता, क्योंकि एडमिन इसे बदल या हटा सकते हैं।

HTTP हेडर लुकअप टूल से बना नतीजे का उदाहरण

समस्याओं की जांच में इसका व्यावहारिक इस्तेमाल

रीडायरेक्ट की समस्या हेडर देखने की एक आम वजह है। मान लें कि https://example.com/old-page से 301 स्टेटस और Location: https://example.com/new-page मिलता है। इसका अर्थ है कि सर्वर क्लाइंट को नए पते पर अनुरोध भेजने का निर्देश दे रहा है। हर गंतव्य को बार-बार जांचने से रीडायरेक्ट लूप या HTTP और HTTPS के बीच अनचाहा बदलाव पकड़ में आ सकता है।

अगर Cloudflare या किसी अन्य CDN के पीछे पुराना पेज दिख रहा है, तो Cache-Control, Age, ETag और सेवा प्रदाता से जुड़े किसी भी कैश हेडर की जांच करें। Age की बड़ी वैल्यू कैश किए गए रिस्पॉन्स की गणना की गई आयु बताती है, जिसमें अपस्ट्रीम कैश में बीता समय भी शामिल हो सकता है। यह यह नहीं बताती कि किसी खास मध्यस्थ ने उसे कितने समय तक अपने पास रखा है। इससे यह भी साबित नहीं होता कि हर क्षेत्रीय कैश में वही संस्करण मौजूद है।

अगर कोई API सर्वर-साइड स्क्रिप्ट में काम करती है लेकिन ब्राउज़र में विफल हो जाती है, तो Content-Type और CORS रिस्पॉन्स हेडर देखें, जिनमें Access-Control-Allow-Origin भी शामिल है। अगर JSON एंडपॉइंट text/html लौटा रहा है, तो हो सकता है कि वह असल में कोई त्रुटि पेज या लॉगिन स्क्रीन दे रहा हो। क्रॉस-ओरिजिन अनुमति न होने पर ब्राउज़र एक्सेस रोक सकता है, भले ही सर्वर ने 200 स्टेटस लौटाया हो।

अगर कोई साइट उपलब्ध नहीं दिख रही है, तो हेडर उस समस्या को समझने में भी मदद कर सकते हैं। 503 रिस्पॉन्स अस्थायी सर्वर या अपस्ट्रीम विफलता की ओर इशारा करता है, जबकि 404 का अर्थ है कि अनुरोधित पाथ नहीं मिला। हालांकि हेडर से हर समस्या का पता नहीं लगाया जा सकता। अगर HTTP रिस्पॉन्स बनने से पहले DNS रिज़ॉल्यूशन, TCP कनेक्शन या TLS नेगोशिएशन विफल हो जाए, तो जांचने के लिए कोई रिस्पॉन्स हेडर नहीं होगा। अलग से कनेक्टिविटी जांचने के लिए पिंग और प्रोटोकॉल सपोर्ट जांचने के लिए HTTP/2 चेकर का इस्तेमाल किया जा सकता है।

सही हेडर मिलने पर भी नतीजा गलत क्यों लग सकता है?

सही नतीजा भी आपके ब्राउज़र से अलग हो सकता है, क्योंकि कैश, DNS रिकॉर्ड और अनुरोध का संदर्भ दोनों अनुरोधों को अलग-अलग रिस्पॉन्स तक पहुंचा सकते हैं। यह लुकअप सर्वर पर चलता है, इसलिए संभव है कि यह किसी दूसरे CDN नोड तक पहुंचे या हाल में बदले DNS रिकॉर्ड को आपके स्थानीय नेटवर्क से पहले या बाद में रिज़ॉल्व करे।

ब्राउज़र अपनी कुकी, स्वीकार किए जाने वाले कंटेंट प्रकार, भाषाएं और कैश वैलिडेटर भी भेजते हैं। इसलिए लॉग इन किए गए WordPress पेज के कैश नियम, सर्वर से भेजे गए अनाम अनुरोध से अलग हो सकते हैं। भौगोलिक रूटिंग और बॉट-मैनेजमेंट सिस्टम भी स्रोत नेटवर्क या अनुरोध हेडर के आधार पर रिस्पॉन्स बदल सकते हैं।

DNS बदलने के बाद भी कैश्ड रिज़ॉल्वर पुराने रिकॉर्ड की टाइम टू लिव अवधि खत्म होने तक उसका इस्तेमाल जारी रख सकते हैं। ट्रैफ़िक नए सर्वर तक पहुंचने लगे, तब भी CDN का पुराना ऑब्जेक्ट या ब्राउज़र कैश पहले की सामग्री लौटा सकता है। रिज़ॉल्व किए गए होस्ट को अलग से जांचें, जहां उचित हो वहां कैश साफ़ करें और यह मानने के बजाय सटीक URL की तुलना करें कि हर होस्टनेम एक ही कॉन्फ़िगरेशन इस्तेमाल करता है।

अक्सर पूछे जाने वाले सवाल

क्या इसमें रिक्वेस्ट हेडर भी दिखते हैं?

नहीं। यह सामान्य GET अनुरोध के लिए URL से लौटे रिस्पॉन्स हेडर प्राप्त करता है। रिक्वेस्ट हेडर वह मेटाडेटा है जो सर्वर को भेजा जाता है। उन्हें पूरी तरह जांचने के लिए ब्राउज़र के अलग डेवलपर टूल, सर्वर लॉग या कमांड-लाइन क्लाइंट की जरूरत होती है।

क्या टूल में डाले गए URL निजी रहते हैं?

लुकअप सर्वर पर किया जाता है। आपका इनपुट HTTPS के जरिए उस सर्वर तक पहुंचता है और उसे स्टोर नहीं किया जाता। ऐसे URL दर्ज न करें जिनमें पासवर्ड, एक्सेस टोकन या संवेदनशील क्वेरी पैरामीटर हों, क्योंकि अनुरोध भेजे जाने पर गंतव्य सर्वर को भी ये वैल्यू मिलेंगी।

क्या HTTP हेडर से सर्टिफ़िकेट चेतावनी का कारण पता चल सकता है?

आम तौर पर केवल HTTP हेडर से इसका पता नहीं चलता। HTTP रिस्पॉन्स भेजे जाने से पहले TLS कनेक्शन स्थापित होता है। इसलिए सर्टिफ़िकेट की अवधि खत्म होने, होस्टनेम मेल न खाने या जारीकर्ता के भरोसेमंद न होने पर कोई हेडर लौटने से पहले ही प्रक्रिया रुक सकती है। अगर पेज लोड होने से पहले ब्राउज़र चेतावनी दिखाता है, तो सर्टिफ़िकेट और उसकी चेन की अलग से जांच करें।

कई Set-Cookie हेडर क्यों मिलते हैं?

एक रिस्पॉन्स एक से अधिक कुकी सेट कर सकता है और हर कुकी का अपना Set-Cookie फ़ील्ड होता है। इन्हें कॉमा से अलग की गई सूची मानकर एक साथ न जोड़ें, क्योंकि कुकी की समाप्ति तारीख में भी कॉमा हो सकते हैं। हर कुकी के डोमेन, पाथ और सुरक्षा एट्रिब्यूट को अलग-अलग जांचें।

क्या नतीजे की तुलना curl से की जा सकती है?

हां। curl -D - https://example.com/ -o /dev/null जैसी कमांड रिस्पॉन्स बॉडी को छोड़ते हुए रिस्पॉन्स हेडर दिखाती है। Curl के अलग संस्करण, रिक्वेस्ट हेडर, रीडायरेक्ट सेटिंग और नेटवर्क स्थान अलग नतीजे दे सकते हैं। इसलिए किसी अंतर को सर्वर की खराबी मानने से पहले इन परिस्थितियों को समान रखें।