HTTP विकल्प के अनुरोध का जवाब कैसे दें?

Question

HTTP OPTIONSविधि का उपयोग यह निर्धारित करने के लिए किया जाता है कि सर्वर किसी दिए गए संसाधन पर किन अन्य तरीकों का समर्थन करता है। यह देखते हुए, मेरे दो प्रश्न हैं:

• यह प्रतिक्रिया कैसी दिखती है? मैं में सीएसवी सूची के साथ उदाहरण देखा है Public, Allowऔर यहां तक कि Access-Control-Allow-Methodsशीर्ष लेख। क्या इन सबकी जरूरत है? क्या फर्क पड़ता है? RFC 2616 यहाँ बहुत उपयोगी नहीं लगती है।

• क्या यह उपयोग उन कार्यों को सूचीबद्ध करने के लिए उपयुक्त होगा जो एक गैर-रीस्ट-एपीआई वातावरण में एक संसाधन का समर्थन करता है? उदाहरण के लिए, अगर मेरी ConversionControllerकार्रवाई का समर्थन करता है convert, तो इस तरह की प्रतिक्रिया होगी:

निवेदन:

OPTIONS /conversion HTTP/1.1

उत्तर:

HTTP/1.1 200 OK
...
Allow: CONVERT
...

Comments

Allow: CONVERT??

— पचेरियर

Answer 1

RFC 2616 "Allow" ( http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7 ) को परिभाषित करता है । "सार्वजनिक" अब उपयोग में नहीं है। "पहुंच-नियंत्रण-अनुमति-विधियाँ" को कोर विनिर्देश में परिभाषित किया गया है (देखें http://www.w3.org/TR/cors/ )।

Comments

स्पष्टीकरण के लिए धन्यवाद। CORS के मामले में, दोनों चाहिए Allowऔर Access-Control-Allow-Methodsभेजा जाना है, या बस उत्तरार्द्ध?

— FtDRbwLXw6

मैं हमेशा "अनुमति" वापस करूंगा, इस प्रकार विशेष-केस कॉर्स नहीं।

— जूलियन रेसके

सामग्री के बारे में क्या? क्या शरीर की सामग्री उपलब्ध हो सकती है?

— CMCDragonkai

@CMCDragonkai हाँ, OPTIONSसामग्री हो सकती है। RFC 2616 से: "यदि विकल्प अनुरोध में एक निकाय-निकाय शामिल है (जैसा कि सामग्री-लंबाई या स्थानांतरण-एन्कोडिंग की उपस्थिति द्वारा इंगित किया गया है), तो मीडिया प्रकार को सामग्री-प्रकार फ़ील्ड द्वारा इंगित किया जाना चाहिए। हालाँकि यह विनिर्देश परिभाषित नहीं करता है। इस तरह के एक शरीर के लिए किसी भी उपयोग, HTTP के भविष्य के एक्सटेंशन सर्वर पर अधिक विस्तृत प्रश्न करने के लिए विकल्प निकाय का उपयोग कर सकते हैं। ऐसा सर्वर जो इस तरह के विस्तार का समर्थन नहीं करता है, अनुरोध निकाय को छोड़ दें। "

— बिशप

मुझे विश्वास है कि दोनों Allowऔर Access-Control-Allow-Methodsआप CORS उपयोग करना चाहते हैं की जरूरत है। पूर्व निर्दिष्ट करता है कि कौन-सी विधियाँ सामान्य और उत्तरार्द्ध में समर्थित हैं, कौन-सी विधियाँ पार-मूल अनुरोधों के लिए अनुमत हैं। उदाहरण के लिए, आप अनुमति दे सकते हैं GET, POST, PUTऔर DELETEअपनी खुद की उत्पत्ति के लिए अनुमति देते हैं, लेकिन केवल GETऔर POSTपार उत्पत्ति के लिए।

— मिकको रैंटलैनेन

Answer 2

शीर्षक के जवाब में: "एक HTTP विकल्प अनुरोध का जवाब कैसे दें?" इसका उत्तर देने के लिए, मैं जानना चाहता हूं कि आप विकल्प के अनुरोध का जवाब क्यों देना चाहते हैं? कौन / क्या आपको विकल्प भेज रहा है, और क्यों? कई सार्वजनिक सर्वर "त्रुटि" या "अनुमत नहीं" (500, 501, 405) के कुछ रूप के साथ प्रतिक्रिया करते हैं । इसलिए, जब तक आप एक विशिष्ट स्थिति में न हों जहां आपके ग्राहक यथोचित विकल्प भेजेंगे और उपयोगी / सार्थक जानकारी वापस पाने की उम्मीद करेंगे (उदाहरण के लिए, WebDAV, CORS), आप शायद इसके साथ जवाब देना चाहते हैं: "ऐसा मत करो।"

"विकल्प / रूपांतरण HTTP / 1.1" अनुरोध के बारे में आपके प्रश्न के संदर्भ में: जब तक आप नहीं जानते कि आपके सर्वर के कुछ ग्राहक हैं, एक ग्राहक जो "/ रूपांतरण" के लिए एक विकल्प अनुरोध भेजेगा और "अनुमति दें: CONVERT" के साथ प्रतिक्रिया की अपेक्षा करेगा , "जवाब नहीं है: यह इस तरह से जवाब देने के लिए समझ में नहीं आता है। मुझे लगता है कि अधिकांश कार्यान्वयन जो विकल्प का समर्थन करते हैं और मानक HTTP विधियों के साथ "अनुमति दें" का जवाब देते हैं।

यहाँ विषय पर एक महान लेख है ।

सारांश: विकल्प तुरंत समस्याग्रस्त है क्योंकि यह कैशिंग का समर्थन नहीं करता है। विकल्प: सर्वर-वाइड मेटाडेटा: प्रसिद्ध URI का प्रयास करें । संसाधन-विशिष्ट: इसकी प्रतिक्रियाओं पर एक लिंक हेडर , या उस संसाधन के लिए प्रतिनिधित्व प्रारूप में एक लिंक का उपयोग करने का प्रयास करें ।

अंत में, यदि आप एक सेवा विवरण के बाद हैं, तो WADL या RSDL पर एक नज़र डालें ।

संपादित करें:

dotnetguy नीचे टिप्पणी में एक अच्छा बिंदु बनाता है: विकल्प निश्चित रूप से कुछ संदर्भों में मूल्यवान हैं (जैसे, कॉर्स); मैं निश्चित रूप से अन्यथा सुझाव देने का मतलब नहीं था।

Comments

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

— सुधांशु मिश्रा

जब मैंने अपने (स्वयं लिखित) http सर्वर को MacOS Finder ( Webdav का उपयोग करके ) से कनेक्ट करने के लिए विकल्प अनुरोधों को देखा ।

— जो

Answer 3

एक HTTP विकल्प अनुरोध क्या है?

यह ग्राहक से एक अनुरोध को पता है कि HTTP विधियों सर्वर की अनुमति देगा की तरह GET, POSTआदि

निवेदन

किसी विशेष संसाधन के विकल्पों के बारे में पूछने पर अनुरोध इस तरह दिख सकता है:

OPTIONS /index.html HTTP/1.1

या इस तरह से जब सामान्य रूप से सर्वर के बारे में पूछते हैं:

OPTIONS * HTTP/1.1

प्रतिक्रिया

प्रतिक्रिया Allowमें अनुमत विधियों के साथ एक हेडर होगा :

Allow: OPTIONS, GET, HEAD, POST

सर्वर HTTP विकल्प अनुरोध क्यों प्राप्त कर रहा है?

• कुछ REST API को इसकी आवश्यकता होती है (लेकिन यदि आप API को परिभाषित कर रहे हैं, तो आपको पता होगा कि)
• ब्राउज़र्स इसे सर्वरों को "प्रीफ़्लाइट" अनुरोधों के रूप में यह देखने के लिए भेजते हैं कि क्या सर्वर कोर को समझता है
• हमलावर एपीआई के बारे में अधिक जानकारी प्राप्त करने के लिए इसे भेजते हैं

HTTP विकल्प के अनुरोध का जवाब कैसे दें?

• आप एक Allowedहेडर के साथ जवाब दे सकते हैं और यहां तक कि शरीर में अपने एपीआई का दस्तावेज भी बना सकते हैं ।
• आप अतिरिक्त कोर परिभाषित Access-Control-Request-*हेडर के साथ जवाब दे सकते हैं ।
• आप के साथ जवाब दे सकता है 405 Method Not Allowedया 501 Not Implemented।

मैं HTTP विकल्प अनुरोध प्राप्त करना कैसे रोकूँ?

• यदि यह एक ब्राउज़र से आ रहा है, तो अपने एपीआई को अपडेट करें ताकि यह कुछ भी "खतरनाक" (जैसे PUTया DELETE, POSTसाथ application/json) नहीं कर रहा है । केवल सरल अनुरोध करें ।

यह सभी देखें

• RFC 2616 धारा 9: विधि परिभाषाएँ
• एमडीएन वेब डॉक्स: विकल्प
• एमडीएन वेब डॉक्स: क्रॉस-ओरिजिनल रिसोर्स शेयरिंग (कोर)
• कॉर्स - प्रीफ़लाइट अनुरोधों को पेश करने के पीछे प्रेरणा क्या है?
• HTTP Methods का शोषण कैसे करें