आप अपने ब्राउज़र में जो कुछ भी देखते हैं वह लगभग HTTP प्रोटोकॉल के माध्यम से आपके कंप्यूटर पर प्रसारित होता है। उदाहरण के लिए, जब आपने यह लेख पृष्ठ खोला, तो आपके ब्राउज़र ने बहुत सारे HTTP अनुरोध ( अनुरोध ) भेजे और बहुत सारी प्रतिक्रियाएँ ( प्रतिक्रिया ) प्राप्त कीं।
HTTP हेडर ( Header ) इन HTTP अनुरोधों और प्रतिक्रियाओं का एक महत्वपूर्ण हिस्सा हैं, वे क्लाइंट के ब्राउज़र, अनुरोधित पृष्ठ, सर्वर आदि के बारे में जानकारी देते हैं।
इस ट्यूटोरियल में हम यह दिखाने जा रहे हैं कि Request Headers से आपको आवश्यक जानकारी कैसे प्राप्त करें। यह ट्यूटोरियल इस बात पर मार्गदर्शन करता है कि अनुरोध हेडर ( Request Headers ) से हम जिस जानकारी में रुचि रखते हैं उसे कैसे प्राप्त करें और आवश्यक प्रतिक्रिया शीर्षलेखों ( Response Headers ) में कुछ मान सेट करें।
Request Headers की सामग्री के बारे में जानकारी प्राप्त करने का सबसे आसान तरीका एक प्रकाशित आवेदन में अनुरोध निष्पादित करना है।
- डेवलपर टूल ( F12 ) पर जाएं।
- Networks टैब पर स्विच करें।
- सूची से सबमिट किए गए अनुरोध का चयन करना।
- Headers टैब पर स्विच करें और Request Headers अनुभाग ढूंढें।
अनुरोध-प्रतिक्रिया शीर्षलेखों के साथ बातचीत करने के लिए ऐपमास्टर का उपयोग कैसे करें
AppMaster बैकएंड डिज़ाइनर में आप अनुरोध शीर्षलेख जानकारी प्राप्त कर सकते हैं यदि उसका नाम Get Request Headers व्यावसायिक प्रक्रिया ब्लॉक में निर्दिष्ट है।
- Name [ string ] - हैडर का नाम;
- Value [ string ] - हैडर का मान;
प्रतिक्रिया में कस्टम Header जोड़ने के लिए - Set Response Header ब्लॉक का उपयोग किया जाता है।
- Name [ स्ट्रिंग ] - हैडर का नाम;
- Value [ स्ट्रिंग ] - हैडर का मान;
कई Request Headers मौजूद हैं, लेकिन उनमें से कुछ नीचे वर्णित हैं (जानकारी https://www.w3.org/Protocols/HTTP/HTRQ_Headers.html से ली गई है):
- From - इंटरनेट मेल प्रारूप में, यह अनुरोध करने वाले उपयोगकर्ता का नाम देता है। इस फ़ील्ड का उपयोग लॉगिंग उद्देश्यों और एक्सेस सुरक्षा के असुरक्षित रूप के लिए किया जा सकता है। इस क्षेत्र की व्याख्या यह है कि अनुरोध दिए गए व्यक्ति की ओर से किया जा रहा है, जो प्रदर्शन की गई विधि के लिए जिम्मेदारी स्वीकार करता है। इस क्षेत्र में इंटरनेट मेल पते का अनुरोध जारी करने वाले इंटरनेट होस्ट के अनुरूप होना आवश्यक नहीं है। (उदाहरण के लिए, जब कोई अनुरोध गेटवे के माध्यम से पारित किया जाता है, तो मूल जारीकर्ता के पते का उपयोग किया जाना चाहिए)। मेल पता, यदि संभव हो, एक वैध मेल पता होना चाहिए, चाहे वह वास्तव में एक इंटरनेट मेल पता हो या किसी अन्य मेल सिस्टम पर किसी पते का इंटरनेट मेल प्रतिनिधित्व हो।
- Accept - इस फ़ील्ड में प्रतिनिधित्व योजनाओं की एक अर्धविराम से अलग की गई सूची है ( Content-Type मेटानफॉर्मेशन मान) जिसे इस अनुरोध के जवाब में स्वीकार किया जाएगा। दिया गया सेट निश्चित रूप से एक ही उपयोगकर्ता के अनुरोध से अनुरोध में भिन्न हो सकता है।
उदाहरण:
स्वीकार करें: टेक्स्ट/सादा, टेक्स्ट/एचटीएमएल
स्वीकार करें: टेक्स्ट/एक्स-डीवीआई; क्यू = .8; एमएक्सबी = 100000; एमएक्सटी=5.0, टेक्स्ट/एक्ससी - Accept-Encoding - स्वीकार के समान, लेकिन सामग्री-एन्कोडिंग प्रकारों को सूचीबद्ध करता है जो प्रतिक्रिया में स्वीकार्य हैं।
उदाहरण:
स्वीकार-एन्कोडिंग: एक्स-संपीड़ित; एक्स-ज़िप - Referer - यह वैकल्पिक हेडर फ़ील्ड क्लाइंट को सर्वर के लाभ के लिए, दस्तावेज़ का पता (यूआरआई) (या दस्तावेज़ के भीतर तत्व) निर्दिष्ट करने की अनुमति देता है, जिससे अनुरोध में यूआरआई प्राप्त किया गया था। यह एक सर्वर को दस्तावेजों के बैक-लिंक की सूची बनाने की अनुमति देता है, ब्याज, लॉगिंग आदि के लिए। यह रखरखाव के लिए खराब लिंक का पता लगाने की अनुमति देता है। यदि आंशिक यूआरआई दिया गया है, तो इसे अनुरोध की वस्तु के यूआरआई के सापेक्ष पार्स किया जाना चाहिए।
उदाहरण:
रेफरर: http://www.w3.org/hypertext/DataSources/Overview.html - Authorization - यदि यह पंक्ति मौजूद है तो इसमें प्राधिकरण जानकारी शामिल है। प्रारूप निर्दिष्ट किया जाना है (टीबीएस)। इस क्षेत्र का प्रारूप एक्स्टेंसिबल रूप में है। पहला शब्द उपयोग में प्राधिकरण प्रणाली का एक विनिर्देश है।
उदाहरण:
प्राधिकरण: वाहक BtHKEsVs5mNNtNf7UWoVwjJzFqLOzucA - Accept-Language - स्वीकार के समान, लेकिन उन भाषा मूल्यों को सूचीबद्ध करता है जो प्रतिक्रिया में बेहतर होते हैं। अनिर्दिष्ट भाषा में प्रतिक्रिया अवैध नहीं है।
- User-Agent - यदि मौजूद है तो यह लाइन मूल क्लाइंट द्वारा उपयोग किए जाने वाले सॉफ़्टवेयर प्रोग्राम को देती है। यह सांख्यिकीय उद्देश्यों और प्रोटोकॉल उल्लंघनों का पता लगाने के लिए है। इसे शामिल किया जाना चाहिए। वैकल्पिक स्लैश और संस्करण डिज़ाइनर के साथ पहला व्हाइट स्पेस सीमांकित शब्द सॉफ़्टवेयर उत्पाद का नाम होना चाहिए। अन्य उत्पाद जो उपयोगकर्ता एजेंट का हिस्सा बनते हैं उन्हें अलग शब्दों के रूप में रखा जा सकता है।
उदाहरण:
उपयोगकर्ता-एजेंट: एलआईआई-सेलो/1.0 libwww/2.5
Response Headers उदाहरण:
- Allowed - अनुरोधों के सेट को सूचीबद्ध करता है जिसे अनुरोध करने वाले उपयोगकर्ता को इस URL के लिए जारी करने की अनुमति है। यदि यह हेडर लाइन छोड़ी जाती है, तो डिफ़ॉल्ट अनुमत विधियाँ " GET HEAD " हैं।
- Public - जैसा कि अनुमति है लेकिन उन अनुरोधों को सूचीबद्ध करता है जिनका कोई भी उपयोग कर सकता है। यदि छोड़ा गया है, तो डिफ़ॉल्ट केवल " GET " है।
- Content-Length - इसका मतलब है कि शरीर द्विआधारी है और इसे संचार लिंक से सीधे पढ़ा जाना चाहिए, बिना लाइनों को पार्स किए, आदि। जब डेटा अनुरोध का हिस्सा होता है, तो समाप्ति अनुक्रम से बचने और भागने से रोकता है।
- Content-Encoding - उपयोग किए गए एन्कोडिंग तंत्र को निर्दिष्ट करता है। वर्तमान में केवल x-compress और x-gzip उपयोग में है।
- Content-Type - दस्तावेज़ प्रकार निर्दिष्ट करता है।
- Content-Length - इसका मतलब है कि शरीर द्विआधारी है और इसे संचार लिंक से सीधे पढ़ा जाना चाहिए, बिना लाइनों को पार्स किए, आदि। जब डेटा अनुरोध का हिस्सा होता है, तो समाप्ति अनुक्रम से बचने और भागने से रोकता है।
- Last-Modified - पिछली बार वस्तु को संशोधित किया गया था, अर्थात इस संस्करण की तिथि यदि दस्तावेज़ एक "जीवित दस्तावेज़" है।
आइए अनुरोध हेडर से उपयोगकर्ता के आईपी और उसके कुकी मूल्य प्राप्त करने का एक उदाहरण देखें।
उपयोगकर्ता का IP प्राप्त करने के लिए x-real-ip का उपयोग किया जाता है। कुकी अनुरोध शीर्षलेख कुकी टोकन जानकारी प्रदान करते हैं।
बीपी ऐसा दिखता है:
इसके लिए अगले स्टेप में एंडपॉइंट बनाना होता है
यूआई जैसा दिखता है:
अंत में, परिणाम नीचे दिखाया गया है। बटन पर क्लिक करने के बाद उपयोगकर्ता को हेडर से जानकारी मिलती है (बटन के वर्कफ़्लो में ट्रिगर पर क्लिक करें) और लेबल के शीर्षक इस जानकारी ( लेबल अपडेट गुण ) के साथ अपडेट हो जाते हैं।
