就相关规范的实际要求而言,答案有两个部分:
-
当浏览器必须在内部将原点设置为将被序列化为
null
-
浏览器必须发送源标题时
详情如下:
当浏览器必须将origin设置为一个值,该值将被序列化为
无效的
HTML规范使用了这个术语
opaque origin
并将其定义为内部值:
没有序列化,它可以从中重新创建(
它被序列化为“null”
每ASCII序列化一次),唯一有意义的操作是测试是否相等
换句话说,HTML规范所说的每一个地方
不透明原点
,你可以把它翻译成
无效的
.
HTML规范要求浏览器在以下情况下设置不透明原点或唯一原点:
-
Cross-origin images (including cross-origin
img
elements)
-
Cross-origin media data (including cross-origin
video
and
audio
elements)
-
Any document generated from a
data:
URL
-
Any
iframe
with a
sandbox
attribute that doesnât contain the value
allow-same-origin
-
Any document programmatically created using
createDocument()
, etc.
-
Any document that does not have a creator browsing context
-
Responses that are network errors
-
The
Should navigation response to navigation request of type from source in target be blocked by Content Security Policy?
algorithm returns Blocked when executed on a navigate response
Fetch规范要求浏览器将原点设置为全局唯一标识符(这基本上与不透明原点的意思相同,不透明原点的意思基本上是
无效的
)在一个案例中:
-
Redirects across origins
URL规范要求浏览器在以下情况下设置不透明原点:
-
For
blob:
URLs
-
For
file:
URLs
-
For any other URLs whose scheme is not one of
http
,
https
,
ftp
,
ws
,
wss
, or
gopher
.
但请注意,仅仅因为浏览器在本质上设置了不透明的源代码
无效的
这并不一定意味着浏览器会发送
Origin
头球。因此,请参阅本答案的下一部分,了解浏览器何时必须发送
起源
头球。
浏览器必须发送源标题时
浏览器发送
起源
由服务器发起的跨源请求的标头
fetch()
或XHR调用,或通过JavaScript库(axios、jQuery等)中的ajax方法,但不适用于正常的页面导航(即,当您直接在浏览器中打开网页时),也不适用于(通常)嵌入网页中的资源(例如,不适用于CSS样式表、脚本或图像)。
但这种描述是一种简化。除了跨源XHR/fetch/ajax调用之外,浏览器发送
起源
标题,以及浏览器发送
起源
嵌入式资源的标题。下面是一个较长的答案。
在规范要求方面:规范要求
起源
仅针对Fetch规范定义为
CORS request
:
A.
CORS请求
是包含
起源
头球。无法可靠地确定其作为
起源
标题
对于方法既不是
GET
也没有
HEAD
.
所以,规范的意思是:
起源
在所有跨来源请求中发送标头,
但是
它也总是发送给所有人
POST
,
PUT
,
PATCH
和
DELETE
甚至要求
同源
邮递
,
放
,
色斑
和
删去
请求(根据Fetch中的定义,这些请求实际上是CORS请求,尽管它们的来源相同)。
浏览器必须发送
起源
header是使用CORS标志集发出请求的任何情况,就HTTP(S)请求而言,CORS标志集是
except
when the
request mode
is
navigate
,
websocket
,
same-origin
, or
no-cors
.
XHR
总是
将模式设置为
cors
.但使用Fetch API,这些请求模式是可以使用
mode
函数的init对象参数的字段
fetch(â¦)
方法:
fetch("http://example.com", { mode: 'no-cors' }) // no Origin will be sent
字体请求总是将模式设置为
科尔斯
所以总是有
起源
头球。
对于任何带有
a
crossorigin
attribute
(
又称作
HTML规范要求浏览器将请求模式设置为
科尔斯
(并发送
起源
标题)。
否则,对于嵌入式资源——任何具有启动请求的URL属性的元素(
<script src>
,样式表,图像,媒体元素)请求的模式默认为
没有cors
; 既然这些要求
收到
请求,也就是说,根据规范,浏览器不会发送任何请求
起源
他们的头球。
当HTML表单元素启动时
邮递
请求,这些请求的模式
邮递
s也默认为
没有cors
与嵌入式资源的默认模式相同
没有cors
.然而,与
没有cors
模式
收到
对于嵌入式资源的请求,浏览器会发送
起源
头球
没有cors
模式
邮递
从HTML表单元素开始。
原因是,正如本答案前面提到的,浏览器总是发送
起源
总头球
邮递
,
放
,
色斑
和
删去
请求。
此外,为了完整性和明确起见:对于导航,浏览器不发送
起源
头球。也就是说,如果用户通过将URL粘贴到浏览器地址栏或通过跟踪另一个web文档的链接直接导航到资源,那么浏览器不会发送任何消息
起源
头球。
ï¼
这个
algorithm in the Fetch spec
这需要浏览器发送
起源
所有CORS请求的标题如下:
附加请求
起源
标题,给出一个请求
要求
,运行以下步骤:
1.让我们
多里金
是用字节序列化请求源的结果
要求
.
2.如果
要求
中国的反应是“污染”
科尔斯
“或者
要求
s模式是“
网袋
“那么
追加
起源
/
多里金
到
要求
标题列表。
3.否则,如果
要求
}}s方法既不是
收到
也没有
头
,
然后:
[同时发送
起源
在这种情况下,标题也是]
第二步需要
起源
要在所有跨源请求中发送的标头,因为所有跨源请求的响应污染设置为“
科尔斯
".
但第三步需要
起源
标题也要发送到
同源
邮递
,
放
,
色斑
和
删去
请求(根据Fetch中的定义,这些请求实际上是CORS请求,尽管它们的来源相同)。
上面描述了Fetch规范目前如何定义需求,因为
change that was made to the spec on 2016-12-09
.在那之前,要求是不同的:
 Â
以前没有
起源
被派往同一个地方
 Â
以前没有
起源
是从一个
<form>
(不含CORS)
因此,问题描述的Firefox行为是规范的内容
先前
必需的,不是什么
目前
要求。