HTTP Request Header Origin Explained
रिक्वेस्ट हेडर Origin: https://example.com क्रॉस-ऑरिजिन रिक्वेस्ट (CORS) के लिए रिक्वेस्ट की उत्पत्ति (origin) बताता है। इसको समझते हैं
Origin रिक्वेस्ट हेडर HTTP में क्लाइंट द्वारा भेजा जाता है ताकि यह बताया जा सके कि रिक्वेस्ट किस उत्पत्ति (origin) से शुरू हुई है। यह विशेष रूप से क्रॉस-ऑरिजिन रिसोर्स शेयरिंग (CORS) के संदर्भ में महत्वपूर्ण है, क्योंकि यह सर्वर को यह तय करने में मदद करता है कि रिक्वेस्ट को स्वीकार करना है या अस्वीकार करना है। आइए इसे संक्षेप में और स्पष्ट रूप से समझें कि Origin हेडर क्या है, इसका उपयोग कैसे होता है, और CORS में इसकी भूमिका क्या है।
Origin हेडर क्या है?
परिभाषा: Origin हेडर उस डोमेन (या URL की उत्पत्ति) को दर्शाता है, जहां से रिक्वेस्ट शुरू हुई है। यह आमतौर पर ब्राउज़र द्वारा स्वचालित रूप से जोड़ा जाता है, जब कोई वेबपेज किसी अन्य डोमेन पर संसाधन (जैसे API, इमेज, स्क्रिप्ट) के लिए रिक्वेस्ट भेजता है।
प्रारूप: Origin: <scheme>://<host>[:<port>]
scheme: प्रोटोकॉल (जैसे http, https)।
host: डोमेन नाम (जैसे example.com)।
port (वैकल्पिक): अगर गैर-मानक पोर्ट हो (जैसे :8080)।
- उदाहरण:
- Origin: https://example.com
- इसका मतलब है कि रिक्वेस्टhttps://example.com से शुरू हुई है।
Origin हेडर का उपयोग
कब भेजा जाता है?
Origin हेडर मुख्य रूप से क्रॉस-ऑरिजिन रिक्वेस्ट में शामिल होता है, यानी जब एक वेबपेज (जैसे https://example.com) किसी भिन्न डोमेन (जैसे https://api.example.org) से संसाधन मांगता है।
यह कुछ HTTP मेथड्स के साथ स्वचालित रूप से जोड़ा जाता है:
- POST, PUT, DELETE जैसे मेथड्स।
- GET या HEAD रिक्वेस्ट, अगर वे CORS-संबंधित हैं (जैसे AJAX कॉल में fetch या XMLHttpRequest)।
- प्रीफ़्लाइट रिक्वेस्ट (CORS preflight, OPTIONS मेथड) में भी Origin हेडर अनिवार्य होता है।
कब नहीं भेजा जाता?
अगर रिक्वेस्ट सेम-ऑरिजिन है (यानी एक ही डोमेन, जैसे https://example.com से https://example.com/api), तो ब्राउज़र आमतौर पर Origin हेडर नहीं जोड़ता।
कुछ गैर-CORS रिक्वेस्ट (जैसे <img> टैग या <script> टैग के लिए) में भी यह शामिल नहीं हो सकता।
CORS क्या है?
क्रॉस-ऑरिजिन रिसोर्स शेयरिंग (CORS) एक सुरक्षा तंत्र है, जो ब्राउज़र में लागू होता है। यह नियंत्रित करता है कि एक डोमेन से शुरू हुई रिक्वेस्ट किसी अन्य डोमेन के संसाधनों तक पहुंच सकती है या नहीं।
समस्या: ब्राउज़र की सेम-ऑरिजिन पॉलिसी (Same-Origin Policy) डिफ़ॉल्ट रूप से क्रॉस-ऑरिजिन रिक्वेस्ट को प्रतिबंधित करती है, ताकि दुर्भावनापूर्ण स्क्रिप्ट्स अनधिकृत डेटा न पढ़ सकें।
CORS का समाधान: CORS सर्वर को यह अनुमति देता है कि वह स्पष्ट रूप से बताए कि कौन से डोमेन (origins) उसके संसाधनों तक पहुंच सकते हैं।
Origin हेडर की भूमिका CORS में
क्लाइंट की ओर:
जब कोई वेबपेज क्रॉस-ऑरिजिन रिक्वेस्ट भेजता है, तो ब्राउज़र स्वचालित रूप से Origin हेडर जोड़ता है। उदाहरण:
GET /api/data HTTP/1.1
Host: api.example.org
Origin: https://example.com
यह बताता है कि रिक्वेस्ट https://example.com से शुरू हुई है और api.example.org से डेटा मांग रही है।
सर्वर की ओर:
सर्वर Origin हेडर को पढ़ता है और यह तय करता है कि रिक्वेस्ट की उत्पत्ति (origin) को संसाधन तक पहुंच दी जाए या नहीं।
सर्वर रिस्पांस में Access-Control-Allow-Origin हेडर शामिल करता है, जो अनुमत डोमेन बताता है:
उदाहरण 1: अगर सर्वर https://example.com को अनुमति देता है:
Access-Control-Allow-Origin: https://example.com
- ब्राउज़र रिस्पांस को स्वीकार करता है।
उदाहरण 2: अगर सर्वर सभी डोमेन को अनुमति देता है:
Access-Control-Allow-Origin: *
- कोई भी डोमेन रिस्पांस पढ़ सकता है (केवल गैर-प्रमाणित रिक्वेस्ट के लिए)।
उदाहरण 3: अगर सर्वर Origin को अनुमति नहीं देता: कोई Access-Control-Allow-Origin हेडर नहीं भेजा जाता, और ब्राउज़र रिक्वेस्ट को ब्लॉक कर देता है (CORS एरर)।
प्रीफ़्लाइट रिक्वेस्ट
जटिल रिक्वेस्ट (जैसे POST JSON डेटा के साथ) से पहले, ब्राउज़र एक OPTIONS रिक्वेस्ट (प्रिफ़्लाइट) भेजता है, जिसमें Origin हेडर शामिल होता है:
OPTIONS /api/data HTTP/1.1
Host: api.example.org
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type
- सर्वर जवाब देता है कि क्या यह रिक्वेस्ट स्वीकार्य है:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type
- अगर अनुमति मिलती है, तो वास्तविक रिक्वेस्ट भेजा जाता है।
Origin हेडर की विशेषताएं
स्वचालित: ब्राउज़र इसे स्वयं जोड़ता है; डेवलपर को मैन्युअल रूप से सेट करने की जरूरत नहीं।
सुरक्षा: यह सर्वर को यह जांचने में मदद करता है कि रिक्वेस्ट विश्वसनीय डोमेन से है या नहीं, जिससे अनधिकृत पहुंच (जैसे CSRF हमले) को रोका जा सके।
पोर्ट शामिलता: अगर डोमेन गैर-मानक पोर्ट (जैसे :8080) पर है, तो वह Origin में शामिल होता है। उदाहरण: Origin: https://example.com:8080।
नल (null) मान:
कुछ मामलों में (जैसे लोकल फ़ाइल से रिक्वेस्ट या सैंडबॉक्स्ड iframe), Origin: null हो सकता है।
यह असामान्य है और अक्सर सर्वर द्वारा अस्वीकार किया जाता है।
उदाहरण: CORS में Origin का उपयोग
परिदृश्य: वेबपेज https://example.com एक AJAX कॉल करता है https://api.example.org/data पर।
क्लाइंट रिक्वेस्ट:
GET /data HTTP/1.1
Host: api.example.org
Origin: https://example.com
सर्वर रिस्पांस (अनुमति):
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Content-Type: application/json
{"message": "Success"}
ब्राउज़र रिस्पांस को स्वीकार करता है, और जावास्क्रिप्ट डेटा पढ़ सकता है।
सर्वर रिस्पांस (अस्वीकार):
HTTP/1.1 200 OK
Content-Type: application/json
{"message": "Success"}
कोई Access-Control-Allow-Origin नहीं है, इसलिए ब्राउज़र रिस्पांस को ब्लॉक करता है, और जावास्क्रिप्ट को CORS एरर मिलता है।
आधुनिक संदर्भ
- CORS का व्यापक उपयोग: CORS आजकल वेब डेवलपमेंट में आम है, क्योंकि API और माइक्रोसर्विसेज़ अलग-अलग डोमेन पर होस्ट किए जाते हैं।
- सुरक्षा: Originहेडर और CORS नीतियां मिलकर यह सुनिश्चित करती हैं कि केवल अधिकृत डोमेन ही संवेदनशील डेटा तक पहुंच सकें।
- वाइल्डकार्ड (*): Access-Control-Allow-Origin: *का उपयोग सार्वजनिक API के लिए होता है, लेकिन यह प्रमाणित रिक्वेस्ट (जैसे कुकीज़ या टोकन के साथ) के लिए काम नहीं करता।
- HTTP/2 और HTTP/3: Originहेडर का उपयोग और अर्थ वही रहता है, लेकिन HTTP/2 में हेडर कम्प्रेशन (HPACK) के कारण यह अधिक कुशल होता है।
संक्षेप में
- Origin: https://example.comबताता है कि रिक्वेस्ट https://example.com से शुरू हुई है। यह CORS के लिए महत्वपूर्ण है, क्योंकि यह सर्वर को रिक्वेस्ट की उत्पत्ति की जानकारी देता है।
- CORS में भूमिका: सर्वरOrigin हेडर को पढ़कर यह तय करता है कि रिक्वेस्ट को अनुमति देनी है या नहीं, और Access-Control-Allow-Origin हेडर के साथ जवाब देता है।
- प्रक्रिया: ब्राउज़र स्वचालित रूप सेOrigin जोड़ता है, और सर्वर इसे जांचकर संसाधन तक पहुंच को नियंत्रित करता है। अगर Origin अनुमत नहीं है, तो ब्राउज़र रिस्पांस को ब्लॉक करता है।
- सुरक्षा: यह अनधिकृत क्रॉस-डोमेन रिक्वेस्ट को रोकता है, जिससे वेब सुरक्षित रहता है।
अगर आपको Origin हेडर, CORS, या किसी खास पहलू (जैसे प्रीफ़्लाइट रिक्वेस्ट, सुरक्षा प्रभाव) पर और विस्तार चाहिए, तो पूछें, मैं और स्पष्ट करूंगा!
टिप्पणियाँ
एक टिप्पणी भेजें