HTTP
क्रॉस ओरिजिन एंड एक्सेस कंट्रोल

टिप्पणियों

क्लाइंट: क्रॉस-ऑरिजनल रिसोर्स शेयरिंग (कोर) रिक्वेस्ट भेजना

Origin हेडर सहित एक क्रॉस-ओरिजनल रिक्वेस्ट भेजी जानी चाहिए। यह इंगित करता है कि अनुरोध कहां से उत्पन्न हुआ है। उदाहरण के लिए, से एक क्रॉस मूल अनुरोध http://example.com को http://example.org इस प्रकार दिखाई देगा:

GET /cors HTTP/1.1
Host: example.org
Origin: example.com

सर्वर अनुरोध निर्धारित करने के लिए इस मान का उपयोग करेगा।

सर्वर: एक कोर अनुरोध का जवाब

एक CorS अनुरोध के जवाब में एक Access-Control-Allow-Origin हेडर शामिल होना चाहिए, जो यह बताता है कि कोर को कोर संसाधन का उपयोग करने की अनुमति क्या है। यह शीर्ष लेख तीन मानों में से एक ले सकता है:

• एक मूल। यह करने का अनुरोध केवल उस मूल से अनुरोध करता है।
• चरित्र * । यह किसी भी मूल से अनुरोधों की अनुमति देता है।
• स्ट्रिंग null । यह कोई CORS अनुरोधों की अनुमति नहीं देता है।

उदाहरण के लिए, मूल http://example.com से CORS अनुरोध के स्वागत पर, यदि example.com एक अधिकृत मूल है, तो सर्वर इस प्रतिक्रिया को वापस भेज देगा:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.com

कोई भी मूल प्रतिक्रिया इस अनुरोध को भी अनुमति देगी, अर्थात:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *

उपयोगकर्ता क्रेडेंशियल्स या सत्र की अनुमति देना

उपयोगकर्ता क्रेडेंशियल या उपयोगकर्ता सत्र को कोर अनुरोध के साथ भेजने की अनुमति देता है, जिससे सर्वर उपयोगकर्ता डेटा को CORS अनुरोधों पर बनाए रखने की अनुमति देता है। यह उपयोगी है अगर सर्वर को यह जांचने की आवश्यकता है कि क्या उपयोगकर्ता डेटा प्रदान करने से पहले लॉग इन किया गया है (उदाहरण के लिए, यदि उपयोगकर्ता लॉग इन है तो केवल एक कार्रवाई कर रहा है - इसके लिए क्रेडेंशियल अनुरोध को क्रेडेंशियल के साथ भेजने की आवश्यकता होगी)।

यह OPTIONS प्रीफ़लाइट अनुरोध के जवाब में Access-Control-Allow-Credentials हेडर भेजकर, पूर्व-प्रकाशित अनुरोधों के लिए सर्वर-साइड प्राप्त किया जा सकता है। एक CORS करने के लिए अनुरोध के निम्नलिखित मामला ले लो DELETE एक संसाधन:

OPTIONS /cors HTTP/1.1
Host: example.com
Origin: example.org
Access-Control-Request-Method: DELETE

HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.org
Access-Control-Allow-Methods: DELETE
Access-Control-Allow-Credentials: true

Access-Control-Allow-Credentials: true रेखा इंगित करती है कि निम्नलिखित DELETE CORS अनुरोध को उपयोगकर्ता क्रेडेंशियल्स के साथ भेजा जा सकता है।

पूर्वनिर्धारित अनुरोध

एक मूल CORS अनुरोध को केवल दो विधियों में से एक का उपयोग करने की अनुमति है:

• प्राप्त
• पद

और केवल कुछ चुनिंदा हेडर। POST CORS अनुरोध केवल तीन सामग्री प्रकारों में से चुन सकते हैं।

इस समस्या से बचने के लिए, अनुरोध जो अन्य विधियों, हेडर या सामग्री प्रकारों का उपयोग करना चाहते हैं, उन्हें पहले एक प्रीफ़लाइट अनुरोध जारी करना चाहिए, जो एक OPTIONS अनुरोध है जिसमें एक्सेस-कंट्रोल अनुरोध हेडर शामिल हैं। उदाहरण के लिए, यह प्रीफ़लाइट अनुरोध है जो जाँचता है कि क्या सर्वर एक PUT अनुरोध स्वीकार करेगा जिसमें DNT हेडर शामिल है:

OPTIONS /cors HTTP/1.1
Host: example.com
Origin: example.org
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: DNT

सर्वर: प्रीफ़्लाइट अनुरोधों का जवाब देना

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

ये एक्सेस-कंट्रोल अनुमति हेडर में इंगित किए गए हैं। सर्वर एक एक्सेस-कंट्रोल Max-Age हेडर को भी वापस भेज सकता है, यह दर्शाता है कि प्रीफ्लाइट रिस्पांस को कितने समय के लिए कैश किया जा सकता है।

यह वह है जो प्रीफ़लाइट अनुरोध के लिए अनुरोध-प्रतिक्रिया चक्र जैसा दिखता है:

OPTIONS /cors HHTP/1.1
Host: example.com
Origin: example.org
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: DNT

HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.org
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Headers: DNT