我有一个从我的 React 应用程序调用的 API 端点。该 API 在同一个域上。…我期待在我的服务器日志上看到一个Origin
标题。
根据 Fetch 规范要求,浏览器不发送Origin
同源请求。GET
✳️
就像已经进行了起源检查
是的——浏览器知道:
- 发出请求的代码的来源
- 发出请求的资源的来源
- 请求方法
…并且浏览器在决定是否添加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
这意味着呼叫是在另一个网站/域中生成的?那是对的吗?
https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header有详细信息:
Sec-Fetch-Site 值 |
值表示什么 |
同源 |
发出请求的来源与发出请求的代码的来源相匹配。 |
同一地点 |
发出请求的来源和发出请求的代码来源具有相同的“可注册域”</em>(有时也称为“相同 eTLD+1”</em>或“相同有效顶级域名加一”</em>);所以,例如,https://subdomain.example.com 和https://example.com 是同一个站点(即使不是同源)。 |
跨站 |
发出请求的来源和发出请求的代码来源既不是同源,也不是同站点,而是具有不同的可注册域。 |
没有任何 |
该请求不是由前端代码以编程方式发起的(例如,不是由 XHR/fetch/ajax 调用),而是由普通用户导航发起的——也就是说,由用户执行类似直接将地址放入浏览器 URL 栏中的操作,或单击超链接。 |
✳️ 导致在Origin
同源GET
请求中省略标头的规范要求:
最终是否Origin
添加标头取决于请求的“响应污染”</a>,其值以“ basic
”开头,对于同源请求,Fetch 算法将其设置为“ basic
”,根据“Main fetch”算法的第 12 步:
↪ request的当前 url 的 origin 与request的 origin 相同,并且request的 response tainting 是 " basic
"
...</p>
- 将请求的响应污染设置为“
basic
”。
- 返回给定fetchParams运行方案 fetch的结果。
运行方案 fetch会导致调用附加请求 `Origin` 标头算法,并且Origin
仅在以下至少一项为真时才导致添加标头:
- 请求的响应污染是“
cors
”
- 请求的模式是“
websocket
”
- 请求的方法既不是
GET
也不是HEAD
但是对于 same-origin GET
,响应污染不是cors
(而是根据上面的要求,它是basic
),请求模式不是websocket
,当然方法也不是GET
也不是HEAD
(它是GET
);因此,该算法要求浏览器不添加Origin
标题。