PROSAGA码农传奇-数据访问控制-Access-Control-Allow-Origin标头如何工作？

Access-Control-Allow-Origin是CORS（跨源资源共享）标头。

当站点A尝试从站点B获取内容时，站点B可以发送Access-Control-Allow-Origin响应标头以告知浏览器某些原始来源可以访问此页面的内容。（来源是一个域，再加上一个方案和端口号。）默认情况下，站点B的页面不能被任何其他来源访问；使用Access-Control-Allow-Origin标头会打开一扇门，供按特定请求来源进行跨域访问。

对于站点B希望站点A可以访问的每个资源/页面，站点B应该为其页面提供响应头：

```
Access-Control-Allow-Origin: http://siteA.com
```

现代浏览器不会完全阻止跨域请求。如果站点A从站点B请求一个页面，则浏览器实际上将在网络级别上获取请求的页面，并检查响应头是否将站点A列为允许的请求者域。如果站点B尚未表明允许站点A访问此页面，则浏览器将触发XMLHttpRequest的error事件，并拒绝对请求JavaScript代码的响应数据。

非简单请求
什么发生在网络层面可以略微比上述解释更加复杂。如果该请求是“非简单”请求，则浏览器将首先发送一个无数据的“预检” OPTIONS请求，以验证服务器将接受该请求。当一个（或两个）同时发生时，请求是不简单的：

使用GET或POST以外的HTTP动词（例如PUT，DELETE）
使用非简单的请求标头；仅有的简单请求标头是：

```
Accept
Accept-Language
Content-Language
Content-Type（当它的值是这仅仅是简单的application/x-www-form-urlencoded，multipart/form-data或text/plain）
```

如果服务器使用与非简单动词和/或非简单头匹配的适当响应头（Access-Control-Allow-Headers对于非简单头，Access-Control-Allow-Methods非简单动词）响应OPTIONS预检，则浏览器将发送实际请求。

假设站点A希望发送一个/somePage非简单Content-Type值的PUT请求application/json，浏览器将首先发送预检请求：

```
OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type
```

请注意，Access-Control-Request-Method和Access-Control-Request-Headers是由浏览器自动添加的；您无需添加它们。该OPTIONS预检获取成功的响应头：

```
Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type
```

发送实际请求时（完成预检后），其行为与处理简单请求的方式相同。换句话说，将预检成功的非简单请求与简单请求视为相同（即，服务器仍必须Access-Control-Allow-Origin再次发送实际响应）。

浏览器发送实际请求：

```
PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }
```

然后服务器发送回Access-Control-Allow-Origin，就像一个简单的请求一样：

Access-Control-Allow-Origin: http://siteA.com
有关非简单请求的更多信息，请参见通过CORS了解XMLHttpRequest。https://stackoverflow.com/a/13400954/710446