2012-11-20 13 views
5

के साथ सीओआरएस पोस्ट मैं सीओआरएस का उपयोग कर किसी भिन्न डोमेन पर किसी सेवा में फ़ाइलों को अपलोड करने का प्रयास कर रहा हूं, लेकिन मूल अस्वीकार होने के कारण वे असफल रहते हैं। जहां तक ​​मैं देख सकता हूं कि सही हेडर का उपयोग करने के लिए इसका उपयोग किया जा रहा है।प्रीफलाइट अनुरोध

जावास्क्रिप्ट का अनुरोध: preflight विकल्प अनुरोध से

var xhr = new XMLHttpRequest(); 
    xhr.open('POST', "https://files.example.com", true);                                
    xhr.setRequestHeader('Content-Type', 'application/json'); 
    xhr.onreadystatechange = function() { 
    if (this.status == 200 && this.readyState == 4) { 
     console.log('response: ' + this.responseText); 
    } 
    }; 

    xhr.send(); 

प्रतिक्रिया:

Access-Control-Allow-Headers:Origin, Authorization, Content-Type 
Access-Control-Allow-Methods:POST, OPTIONS 
Access-Control-Allow-Origin:* 
Content-Length:0 
Content-Type:application/json 
Date:Mon, 19 Nov 2012 23:30:21 GMT 

पोस्ट अनुरोध के लिए शीर्ष लेख:

Cache-Control:no-cache 
Content-Type:application/json 
Origin:https://www.example.com 
Pragma:no-cache 
Referer:https://www.example.com 
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_0) AppleWebKit/537.19 (KHTML, like  Gecko) Chrome/25.0.1325.0 Safari/537.19 

कौन-सा त्रुटि में परिणाम है:

XMLHttpRequest cannot load https://files.example.com. Origin https://www.example.com is not allowed by Access-Control-Allow-Origin. 
+0

क्या आपको इसके लिए समाधान मिला है मुझे भी इसी तरह की समस्या का सामना करना पड़ रहा है http://stackoverflow.com/questions/15094620/unable-to-make-cors-post-request-in-javascript-to-java-web-servicejersey/150 9 6479 –

+1

क्या यह अनुरोध प्रमाणित है? यदि ऐसा है, तो एक्सेस-कंट्रोल-अनुमति-उत्पत्ति को उत्पत्ति से मिलान करने की आवश्यकता है (वाइल्डकार्ड का उपयोग नहीं कर सकता)। – maxbeatty

उत्तर

0

प्रीफलाइट में अनुमत शीर्षकों की सूची में कैश-कंट्रोल और प्राग्मा जोड़ने का प्रयास करें। पूर्ण हेडर इस तरह दिखना चाहिए:

Access-Control-Allow-Headers: Cache-Control, Pragma, Origin, Authorization, Content-Type 
1

सबडोमेन अलग हैं। जहां तक ​​सीओआरएस का संबंध है उपडोमेन, प्रोटोकॉल और बंदरगाह उत्पत्ति और अभिगम-नियंत्रण-अनुमति-उत्पत्ति में समान होना चाहिए।

अपने उदाहरण में ऐसा लगता है कि मूल है: https://www.example.com और पहुंच-नियंत्रण-अनुमति दें-उत्पत्ति है: https://files.example.com

+0

लेकिन उन्होंने एक्सेस-कंट्रोल-अनुमति-उत्पत्ति का उपयोग किया: *, जो हर मूल का समर्थन करता है – Oooogi

1

दुर्भाग्य से, अपने पृष्ठ के elicits CORS के अलावा किसी अन्य डोमेन पर पोस्ट। इसमें विभिन्न सबडोमेन, पोर्ट्स और प्रोटोकॉल (http/https) भी शामिल हैं।

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

यदि उन 50-200 एमएस आपके लिए महत्वपूर्ण हैं, तो आप "सरल" सामग्री प्रकार को समझने के लिए अपनी वेब सेवा को फिर से लिख सकते हैं। यदि नहीं, तो आपको अपनी वेब सेवा को HTTP स्थिति 204 (कोई सामग्री नहीं) वापस फेंकना चाहिए जब इसे OPTIONS (http विधि) के साथ कार्य किया जाता है।

जब एक WCF के साथ काम:

WebOperationContext.Current.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.NoContent; 
0

यह थोड़ा देर से, लेकिन आपकी जानकारी को देख यह उड़ान-पूर्व CORS जांच ठीक से काम करता है पता चलता है, यह सिर्फ वास्तविक (2) CORS अनुरोध जहां प्रतिक्रिया हो जाता है ब्राउज़र द्वारा अवरुद्ध

यह एक दयालुता है जिसमें आपने वास्तविक (द्वितीय) सीओआरएस अनुरोध के लिए प्रतिक्रिया शामिल नहीं की है क्योंकि इसमें प्रतिक्रिया अस्वीकृति के लिए सुराग शामिल हो सकता है।

Access-Control-Allow-Origin:* 

... अपने वास्तविक (2) प्रतिक्रिया शामिल नहीं हो सकता है कि शीर्ष लेख, जिस स्थिति में ब्राउज़र ठीक से प्रतिक्रिया को खारिज कर दिया: मेरा संदेह हालांकि पूर्व उड़ान प्रतिक्रिया सही ढंग से शीर्षक शामिल है। अगर मेरी धारणा सच है, तो समाधान केवल इस हेडर को वास्तविक (गैर प्री-फ्लाइट) प्रतिक्रिया में शामिल करना होगा।

संबंधित मुद्दे