为什么预检请求在获取请求之后才发送？

Question

这很奇怪，希望有经验的人告诉我原因。

因此我使用 AWS APIGATEWAY 创建 lambda 代理。我将 CORS 预检添加到 API 的根目录。

但是，当我尝试从前端调用此类 API（使用 Amplify SDK 的 API）时，我注意到 OPTIONS 请求在 GET 请求之后发送。这让我很纳闷，难道不应该反过来吗？其中 OPTIONS 请求带回允许的来源，然后 GET 请求将在标头中携带该来源？

如下图所示，第二个请求是 OPTIONS 请求，而第一个请求是 GET 请求（通过 OPTIONS 请求进行“身份验证”）

但是这不是故事的结局？？？！

如果我将原点更改为 *，则顺序将恢复为我认为正确的顺序。

所以我真的真的真的很困惑，希望有人能帮助我摆脱困境。

提前致谢！

我希望 CORS 预冲突请求在实际请求之前发送。

Answer 1

您所观察到的顺序的可能解释是，从浏览器的角度来看，实际请求是在关联的预检请求之前发起/开始（如果不是发送）。

没有完美的比喻，但您可以将浏览器视为客户端（发起实际请求）和服务器之间的某种拦截代理。下图说明了预检的启动与实际请求之间的相对顺序：

1. 客户端首先发起跨域请求（恰好不简单）；
2. 浏览器暂时暂停实际请求并发送预检请求。