问题描述
我目前正在部署一个基本的API到我的活动服务器，我正在（我认为是）一个CORS问题，但有一些行为，我不能解释。
I'm currently deploying a basic API to my live server and I'm running into (what I think is) a CORS problem but there is some behavior going on that I can't explain.
我正在从一个AngularJS前端通讯到一个Laravel 5（+ ）后端。
I'm communicating from an AngularJS front-end to a Laravel 5 (+ laravel-cors) back-end.
我开始测试一个简单的jQuery AJAX调用（下面），当我从我的本地Vagrant环境（ application / json，而不是multipart / form-data）。换句话说，如果不能使用JavaScript不能发送请求，则请求不是简单的。例如，< form> 提交或来自< script src =...> 将总是发送简单请求。对于非简单请求，浏览器必须预检请求。这意味着浏览器会在原始请求之前发送一个中间请求（称为预检）。 此预检请求是一个 OPTIONS 请求。服务器必须在对此预检的响应中返回头，以确认原始请求的任何非标准属性。如果是，则浏览器将发送原始请求。
Regarding your bewilderment as to why the request is being sent in the first place, that comes down to a distinction between "simple" and "non-simple" CORS requests. For simple CORS requests, the request will always be sent to the server, but the client/JS will not be able to parse the response without proper acknowledgement from the server. Some CORS requests are not simple, so to speak. These are, for example, DELETE or PATCH requests, or POST/GET requests that contain non-standard headers (such as X-headers or a Content-Type of "application/json" as opposed to "multipart/form-data"). In other words, a request is not simple if it cannot be sent without JavaScript. For example, a <form> submit, or a GET request from a <script src="..."> will always send "simple" requests. For non-simple requests, the browser must "preflight" the request. This means that the browser sends an intermediate request, called a preflight, before the original request. This preflight request is an OPTIONS request. The server must than return headers in the response to this preflight that acknowledge any non-standard properties of the original request. If it does, then the browser will send the original request.
您可以在。
这篇关于Access-Control-Allow-Origin错误，但请求通过的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！