获取 API 默认跨域行为

Question

该取规格说的默认获取模式是“无CORS” -

请求具有关联的模式，即“同源”、“cors”、“no-cors”、“导航”或“websocket”。除非另有说明，否则它是“no-cors”。

但是，我似乎注意到了mode: 'no-cors'与未指定模式之间的这种行为差异。如此JSFiddle 示例中所示，将模式显式定义为“no-cors”会使 Javascript 无法访问响应，而未指定模式会使 Response 对象可用于调用方法。

显式指定获取模式的工作方式与内部使用相同模式的默认行为是否不同？我在这里缺少什么？

Answer 1

对于跨域请求，Fetch 算法将请求的“响应污染”设置为cors并要求使用CORS 协议执行提取。

具体参见“Main fetch”算法第12步的以下子步骤：

? request的当前 url 的来源与request的来源相同，并且未设置CORS 标志
？请求的当前 url 方案是“ data”
？请求的模式是“ navigate”或“ websocket”
1. 将请求的响应设置为“ basic”。
2. 使用request返回执行方案获取的结果。
……
？request的模式是 " no-cors"
1. 将request的响应污点设置为 " opaque"。
2. 使用request返回执行方案获取的结果。

否则
1. 将请求的响应污点设置为“ cors”。
2. 使用设置了CORS 标志的请求返回执行 HTTP 获取的结果。

它的意思是，如果请求 URL 与您的代码的来源不同，并且方案不是data，并且模式不是navigate或未websocket显式设置为no-cors，则达到否则条件，并且使用CORS 协议发出请求。

这种解释简化了一些事情，因为在请求具有触发浏览器进行预检的特征的情况下，在上面有一个子步骤，否则到达子步骤 - 但同样在这种情况下，“响应污染”被设置到cors。

但是，我似乎注意到了mode: 'no-cors'与未指定模式之间的这种行为差异。

不同之处在于，当您mode: 'no-cors'为请求显式设置时，在这种情况下，“? 请求的模式是“no-cors””子步骤，而不是“否则”子步骤。

（虽然我认为也许可以改进规范以更清楚地表明当时的模式实际上并不只是默认no-cors- 这就是您可能基于“除非另有说明，否则它是no-cors“”声明的结论来自问题中引用的规范。）

如此 JSFiddle 示例所示，将模式明确定义为“no-cors”会使 Javascript 无法访问响应，

对——那是因为它会导致“？请求的模式是“主要获取”算法中的“无cors”子步骤，而不是其他子步骤。

虽然不指定模式使 Response 对象可用于调用方法。

因为之后会到达“否则”子步骤，因此会执行启用 CORS 的提取。

显式指定获取模式的工作方式与内部使用相同模式的默认行为是否不同？

是的，对于跨域请求，显式设置会mode: 'no-cors'强制在不使用 CORS 的情况下发出请求，而未指定它会导致使用 CORS 发出请求。

但正如上面提到的，我认为也许规范应该得到改进，以便更清楚地了解这一点。

我认为“除非另有说明，否则no-cors关于模式的“”声明绝对不是要指定使用fetch(…)未指定显式模式的方法发出的请求最终将其模式锁定到no-cors.