sec-fetch-site 标头是什么意思？为什么 Origin 标头未定义？

我有一个从 React 应用程序调用的 API 端点。 API 在同一个域中。类似的东西：

https://www.example.com
https://www.example.com/api/update-something

我使用 cross-fetch 来执行该请求。

我希望在我的服务器日志中看到 Origin 标头。事实上，我期待看到 Origin: https://www.example.com .

但这是我得到的：

Origin: undefined

// AND I ALSO GET THESE HEADERS

"sec-fetch-dest":"empty","sec-fetch-mode":"cors","sec-fetch-site":"same-origin"

它们是什么意思？好像 Origin 检查已经完成？

例如：如果我得到 sec-fetch-site: cross-site，这意味着调用是在另一个网站/域中生成的？对吗？

参考：

sec-fetch-site: cross-site
sec-fetch-site: same-origin
sec-fetch-site: same-site
sec-fetch-site: none

我有一个从 React 应用程序调用的 API 端点。该 API 位于同一域中。 ... 我期待在我的服务器日志中看到一个 Origin 标头。

根据 Fetch 规范要求，浏览器不会在同源 Origin 请求中发送 GET 标头。 ✳️

好像已经进行了Origin检查

是的——浏览器知道：

...浏览器会在决定是否添加 Origin 标头之前检查所有这些；如果来源匹配且方法为 Origin，则它们不会添加 GET 标头。

// AND I ALSO GET THESE HEADERS
"sec-fetch-dest":"empty","sec-fetch-mode":"cors","sec-fetch-site":"same-origin"

它们是什么意思？ ... 例如：如果我得到 sec-fetch-site: cross-site，这意味着调用是在另一个网站/域中生成的？对吗？

Sec-Fetch-Site 值	值表示什么
同源	发出请求的来源与发出请求的代码的来源相匹配。
同一站点	发出请求的源和发出请求的代码的源具有相同的“可注册域”（有时也称为“相同的 eTLD+1 ” 或 “相同有效的顶级域加一个”)；因此，例如，`https://subdomain.example.com` 和 `https://example.com` 是同一站点（即使不是同源）。
跨站	发出请求的源和发出请求的代码的源既不是同源也不是同一站点，而是具有不同的可注册域。
无	请求不是由前端代码以编程方式发起的（例如，不是由 XHR/fetch/ajax 调用发起）而是由普通用户导航发起的——也就是说，由用户执行诸如直接将地址放入浏览器网址栏，或点击超链接。

✳️ 导致在同源 Origin 请求中省略 GET 标头的规范要求：

是否添加 Origin 标头最终取决于请求的 “response tainting”，其值以“basic”开头，对于同源请求，提取算法保持设置为“basic”，按照 “Main fetch” algorithm 的第 12 步：

↪ request 的当前 url 的来源与 request 的来源相同来源，请求的响应污染是“basic”
……

运行 scheme fetch 会导致调用 append a request `Origin` header 算法，并且只有在以下至少一项为真时才会添加 Origin 标头：

但是对于同源 GETs，响应污染不是“cors”（相反，根据上面的要求，它是“basic”），请求模式是't "websocket"，当然请求的方法既不是 GET 也不是 HEAD（它是 GET）；因此，该算法要求浏览器不要添加 Origin 标头。

Origin 标头与 CORS 请求以及 POST 请求一起发送。使用 HEAD 或 GET 方法的 Fetch 请求上未设置 Origin 标头