【发布时间】：2021-08-17 03:42:27
【问题描述】：
首先，请纠正我对CORS机制的理解。
在一个非常高的层次上，我的理解是
- 发送带有
Origin标头和http://example.comurl 值的请求 - 如果 origin 是白名单之一，则返回带有
Access-Control-Allow-Origin:http://example.com标头的成功响应 - 如果来源不是白名单之一，则返回 403 Forbidden
再深入一点，我想知道究竟是什么设置了标头以及究竟是什么引发了 403。
是这样吗
-
浏览器自动设置
Origin标头 - 如果源不在白名单中，则无论如何都会返回成功的响应，只是没有
Access-Control-Allow-Origin响应标头 - 然后Browser将丢失的
Access-Control-Allow-Origin转换成403
还是这样
-
浏览器自动设置
Origin标头 - 服务器发现源不在白名单中，并返回 403 响应
所以我的问题是
谁负责生成 403？上面场景一的浏览器还是上面场景二的服务器？
我问是因为在泽西世界，我们有一个似乎遵循上述场景 1 的实现。但在 Spring Boot 世界中，Cors 似乎遵循场景 2。
编辑
从下面的 cmets 中，听起来 Spring Boot 通过抛出 403 做的比它需要的更多。现在我的新问题是，如果原点不在，有没有办法防止 Spring Boot 自动抛出返回 403白名单，而不是像 CORS 协议定义的那样设置 Access-Control-Allow-Origin
【问题讨论】：
-
问题列表中的第 1 步项目（浏览器发送 Origin 标头）是问题中描述 CORS 协议中定义的标准行为的唯一语句。第 2 步（服务器检查白名单）不是 CORS 协议要求或定义的。相反，就 CORS 协议而言，服务器可以发送 Access-Control-Allow-Origin 响应标头，也可以不发送（无论出于何种原因，无论服务器选择做什么），服务器都可以设置 Access-Control -Allow-Origin 响应标头到它想要的任何原始值，或
*。 -
403 响应根本不是 CORS 协议的标准部分。无论出于何种原因，服务器都可以随时响应 403。而且 CORS 规范没有定义任何要求服务器响应 403 的情况。问题中描述的唯一部分实际上由 CORS 规范定义的是 Access-Control-Allow-Origin 响应标头。
-
并且要明确一件事：浏览器绝对不会将丢失的 Access-Control-Allow-Origin 标头转换为 403。403 是一个 HTTP 响应代码——并且所有 HTTP 响应代码都是由服务器而不是浏览器发出的。在任何情况下，浏览器本身都不会发出 403 响应——既不是 CORS 的一部分，也不是任何其他标准协议的一部分。无论出于何种原因，服务器都可以返回他们想要的任何响应代码。因此，当您在浏览器中看到 403 或任何其他 HTTP 响应代码时，浏览器只是按原样传递服务器发送的任何响应代码。
-
听起来 Spring Boot 通过返回 403 正在做一些它不需要的额外操作。
-
是的，在这种情况下不需要发送 403 的原因是存在或不存在 Access-Control-Allow-Origin 响应标头和 Access-Control-Allow-Origin 值，足以向浏览器传达浏览器不应允许访问响应。除了浏览器自己对 Access-Control-Allow-Origin 标头的处理之外，403 响应代码不会导致任何其他事情发生。这就是为什么 200 OK 成功响应是适当且足够的：它只是意味着，请求已收到，我们正在发送响应以供客户端处理
标签： spring-boot cors jersey