为什么预检 (OPTIONS) 请求列在实际 (GET) 请求之后？

Question

我正在测试跨源网络请求。我发现在 Chrome 中，大多数情况下，预检 OPTION 请求是在实际 GET 请求之后出现的。这是 Chrome 开发者工具的“网络”选项卡中显示的顺序。

浏览器不应该先收到OPTION响应才可以决定是否发送GET请求吗？

Answer 1

请求的开始时间（或

发起时间

）与浏览器实际发送请求的时刻并不对应。 一个解释

根据

Chrome的文档

，

默认情况下，请求表中的请求按

发起时间

排序[并按升序排列]。

但是

发起时间

并不对应于浏览器实际发送请求的时刻！从浏览器的角度来看，实际请求是在关联的预检请求之前发起/开始（如果不是发送）。 您可以将浏览器视为客户端（发起实际请求）和服务器之间的某种中介。下图（借自

其他地方

）说明了预检和实际请求的顺序：

客户端首先

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

你可以看到

实际请求在预检请求之前

开始，但是
• 实际请求已发送（如果预检成功），因此仅在预检请求结束
之后
• 结束。 一个实验

在此页面上打开 Chrome 的 DevTools。

转到控制台选项卡并执行以下代码：

fetch('https://www.example.com', {method: "PUT"})
2. 转到网络选项卡。请注意，请求是 按其

   开始时间

   升序排序。 因此，预检请求位于底部。
3. 现在右键单击任何列标题并选择瀑布>
结束时间
4. 。请注意，预检请求现在位于顶部。