为什么CORS在不同的内容类型中给出不同的响应 [英] Why CORS gives different response at different content-types
问题描述
在没有请求内容类型的情况下调用第三方域的服务器时，我收到CORS错误而没有响应。但是当使用内容类型text / plain（这是响应的真实内容类型）进行调用时，我得到一个响应但是有一个CORS错误，所以我无法将其解析为dom。问题是为什么回应是第二次而不是第一次。两者仍然是CORS错误。如何从服务器获得响应后第二次解析错误？
When making a call to the server of the third party domain without a request content type, I get a CORS error and no response. But when making a call with a content type text/plain (which is the the true content-type of the response) then I get a response but with a CORS error so I am unable to parse that to the dom. The question is why is the response coming the second time and not the first time. Both are still a CORS error. How can I parse the error the second time since I am getting a response from the server?
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<script>
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://www.w3schools.com/xml/ajax_info.txt', true);
xhr.setRequestHeader('content-type', undefined);
xhr.onload = function () {
console.log('Test');
};
xhr.send(null);
var contentXHR = new XMLHttpRequest();
contentXHR.open('GET', 'http://www.w3schools.com/xml/ajax_info.txt', true);
contentXHR.setRequestHeader('content-type', 'text/plain');
contentXHR.onload = function () {
console.log('Test request header');
};
contentXHR.send(null);
</script>
</head>
<body>
Check console and network tab
</body>
</html>
推荐答案
当你穿上指定 Content-type ，XHR执行 CORS预检请求。请注意，您的请求是 OPTIONS ，而不是 GET 。这就是为什么你没有从网络选项卡得到任何回复。
When you don't specify Content-type, XHR executes a CORS preflight request. Note that your request is OPTIONS, and not GET. That's why you don't get any response from the network tab.
根据 CORS规范：
一个标题据说是一个简单标题如果标题字段名称是对于Accept，Accept-Language或
Content-Language的
ASCII不区分大小写的匹配，或者它是ASCII不区分大小写的匹配for
Content-Type和标题字段值媒体类型（不包括
参数）是
application / x-www-form-urlencoded，multipart / form-data的ASCII不区分大小写的匹配项，或text / plain。
A header is said to be a simple header if the header field name is an ASCII case-insensitive match for Accept, Accept-Language, or Content-Language or if it is an ASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain.
（...）
如果资源作者稍微复杂一点希望能够使用除简单的
方法之外的方法来处理跨源请求的
。在这种情况下，作者需要回复使用OPTIONS方法的预检请求
，然后需要处理使用所需方法的实际
请求（在此示例中为DELETE）并给出
一个适当的回应。
It gets slightly more complicated if the resource author wants to be able to handle cross-origin requests using methods other than simple methods. In that case the author needs to reply to a preflight request that uses the OPTIONS method and then needs to handle the actual request that uses the desired method (DELETE in this example) and give an appropriate response.
总之，如果你的Content-Type不同于 application / x-www-form-urlencoded ， multipart / form-data ，或 text / plain ，XHR将触发预检（发送 OPTIONS http动词）。
So, in summary, if your Content-Type is different than application/x-www-form-urlencoded, multipart/form-data, or text/plain, XHR will trigger the preflight (send a OPTIONS http verb).
这篇关于为什么CORS在不同的内容类型中给出不同的响应的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
