具体来说，只要您的跨域请求没有导致浏览器执行预检OPTIONS请求，然后该请求将在服务器端成功-但是，因为服务器对该请求的响应中不包含Access-Control-Allow-Origin响应标头，您的浏览器将阻止您的前端代码实际查看服务器发送的响应.但是，如果打开浏览器devtools，仍然可以在其中看到响应.但是，仅仅是因为浏览器收到了响应并且您可以在devtools中看到它，并不意味着浏览器会将响应公开给您的代码.仅当它具有Access-Control-Allow-Origin时才会公开.所有这些似乎都违反直觉，但是如果您记得浏览器是强制执行跨域限制的唯一点，那一切都说得通.服务器不会阻止跨域请求.当您发送请求的服务器接收请求时，它不会检查来源来决定是否响应.服务器只接受请求并对其进行处理，然后发送响应.但是随后浏览器阻止了您的代码访问该响应.但是请记住，浏览器不会阻止您的代码发送请求跨源的 .当请求具有触发浏览器执行预检.因此，如果您的请求不是触发预检的请求，则浏览器会发送该请求，服务器会接收并处理该请求.并且，如果请求方法是POST或其他目的是更改服务器上的状态(在这种情况下，您可能不太在乎响应是什么)，则该请求在服务器端起到了预期的作用，则可以认为是成功的.但是请考虑一下，当您实际上非常关心响应是什么时:请考虑对于GET请求所发生的事情，其中发出请求的全部目的是取回响应.如上所述，如果请求不是触发预检的请求，则浏览器将其发送，服务器将其接收并返回响应.但是，如果响应中不包含Access-Control-Allow-Origin响应标头，则您的浏览器将不允许您的前端JavaScript代码访问它.显然，由于发出GET请求的全部目的是对响应进行某些操作，因此在这种情况下，如果您的代码无法访问响应，那将是一个完全失败的硬性-与POST请求，请求正文实际上仍然按预期方式发布，但是您只是没有办法让代码检查响应以查看请求是否成功.I do an HTTP POST request to the microsoft login to get an access token to use with the mail API, the request succeeds but the code goes to the error clause of my code. requestAccessToken(code: string){console.log("request access token");if (code) { var headers = new Headers(); headers.append("Content-Type", 'application/x-www-form-urlencoded'); headers.append('Accept', 'application/json'); var requestoptions = new RequestOptions({ headers: headers }); var body = `grant_type=authorization_code& redirect_uri=http://localhost:4200& code=`+ code + `& client_id=4e[................]5ab& client_secret=CE[..............]BC`; this.http.post("https://login.microsoftonline.com/common/oauth2/v2.0/token", body, requestoptions).map((res: Response) => { console.log("response given"); const data = res.json(); }).subscribe( (data) => { console.log("The data is = " + data); }, error => { console.log("The error is = " + error) });}The browser console shows this:XMLHttpRequest cannot load https://login.microsoftonline.com/common/oauth2/v2.0/token. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access.zone.js:2019 XHR failed loading: POST "https://login.microsoftonline.com/common/oauth2/v2.0/token".outlook.service.ts:96 The error is = Response with status: 0 for URL: nullhere's a screenshot to show it betterNow the real problem is that my request succeeds as shown below:and the response shows my access token. So why cannot I get it from code? Why does it go the error-clause. 解决方案 What you’re seeing is expected behavior when sending a cross-origin request to a server but not receiving the Access-Control-Allow-Origin response header in the response.Specifically, as long as your cross-origin request has no characteristics that cause your browser to do a preflight OPTIONS request before making your request, then the request will succeed on the server side — but, because the response from the server to that request doesn’t include the Access-Control-Allow-Origin response header, your browser blocks your frontend code from being able to actually see the response the server sends.However, if you open browser devtools you can still see the response there. But just because the browser received the response and you can see it in devtools, it doesn’t mean the browser will expose the response to your code. It’ll only expose it when it has Access-Control-Allow-Origin.That all may seem counter-intuitive but it all makes sense if you remember that the browser is the only point at which cross-origin restrictions are enforced. Servers don’t block cross-origin requests.When the server you’re sending that request to receives the request, it doesn’t check the origin to decide whether to respond. The server just accepts the request and processes it and then sends a response. But then the browser blocks your code from access to that response.But it’s also important to remember that the browser doesn’t block your code from sending that request cross-origin. Browsers only block cross-origin requests from being sent when the requests have qualities (like special headers) that trigger the browser to do a preflight.So if your request isn’t one that triggers a preflight, the browser sends it and the server receives it and processes it. And if the request method is POST or some other whose purpose is to change state on the server — in which case you may not care much what the response is — then to the degree that the request had the intended effect on the server side, it can be considered successful.But consider what happens when you do actually care a lot what the response is: Consider what happens for GET requests, where the entire point of making the request is to get back a response.As explained above, if the request isn’t one that triggers a preflight, the browser sends it, the server receives it, and returns a response. But if the response doesn’t include the Access-Control-Allow-Origin response header, your browser won’t let your frontend JavaScript code access it.Obviously since the entire point of making a GET request is to do something with the response, then in that case if your code can’t access the response, that’s a hard, total failure — in contrast to the case of the POST request, where the request body does actually still get posted as expected, but you just don’t have a way for your code to check the response to see if the request succeeded. 这篇关于请求在服务器上成功，但在浏览器中导致CORS错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！
