前提：
当一个站点 ( http://example.com ) 尝试进行跨域请求时，浏览器会向跨域服务器 ( http://other-server.com ) 发送一个带有 header的 HTTP 请求Origin: http://example.com。如果http://other-server.com上的服务器批准http://example.com作为有效来源，那么它将 1) 正确响应并且 2) 将响应标头设置为Access-control-allow-origin: http://example.com
我的问题是 - 为什么需要Access-control-allow-origin在响应中设置标题？没有错误地响应是否已经确认服务器（http://other-server.com）允许跨域请求？
这种额外的确认层为服务器提供了很大的灵活性来决定它们如何支持 CORS。例如：
1）服务器在设置标头时有很多选择Access-Control-Allow-Origin。它可以使用该*值来允许所有客户端，也可以使用源的实际值（例如http://example.com）来限制客户端的范围。如果服务器确实支持 CORS，但不是针对所有来源，它可以无错误地响应，但Access-Control-Allow-Origin可以设置为http://notyourorigin.com.
Access-Control-Allow-Methods2) CORS 通过和Access-Control-Allow-Headers预检响应标头提供更大的灵活性。这些标头超越了简单的二进制成功/错误 HTTP 状态，并提供了有关服务器支持和不支持的更多细微差别的信息。
正如上面的示例所指出的，没有任何上下文的错误响应可能会让用户非常困惑。如果您发出 CORS 请求，而您得到的只是错误响应，那么您不知道该请求失败的原因。你做错了请求吗？服务器是否完全支持 CORS？如果没有任何随附信息，这可能很难弄清楚。这Access-Control-*为用户提供了更多上下文，因此他们可以有效地调试他们的 CORS 请求。