fetch API 中的 request.mode 有什么意义，尤其是在 cors 方面？答案

【问题标题】：What is the point of request.mode in the fetch API, especially with respect to cors?fetch API 中的 request.mode 有什么意义，尤其是在 cors 方面？
【发布时间】：2018-05-23 22:53:49
【问题描述】：

查看新的 fetch API，您可以在请求中指定模式字段。来自Mozilla：

The mode read-only property of the Request interface contains the mode 
of the request (e.g., cors, no-cors, same-origin, or navigate.) This is 
used to determine if cross-origin requests lead to valid responses, and 
which properties of the response are readable.

然后是如何使用它：

var myHeaders = new Headers();

var myInit = { method: 'GET',
           headers: myHeaders,
           mode: 'cors',
           cache: 'default' };

fetch('flowers.jpg', myInit).then(function(response) {
  return response.blob();
}).then(function(myBlob) {
  var objectURL = URL.createObjectURL(myBlob);
  myImage.src = objectURL;
});

我不明白您为什么需要具体说明在请求本身中如此不言自明的内容？如果我从客户端网站http://client.com 上的http://foo.com 服务器请求资源，服务器是否没有要查看的原始标头？这种模式不会引起混乱吗？

此外，我想弄清楚mode: same-origin 的目标是什么？ “您可以使用它来确保始终向您的源发出请求。” 但是，如果您要发送请求，或者如果其他开发人员可以访问代码，为什么不这样做呢？你只是不发送请求而不是一个字段来表明它是无效的？

【问题讨论】：

标签： javascript xmlhttprequest cors frontend fetch-api

【解决方案1】：

与服务器无关；无论如何，服务器都会收到请求。 Fetch 和 XMLHttpRequest 都是如此。如果您的服务器很天真并且做了一些愚蠢的事情，无论谁在传递什么，从哪里传递，那都是它自己的错，这与阻止它无关。

这与客户端将让您看到的响应内容以及发送到服务器的内容有关（就通过标头的凭据而言，与credentials 字段一起使用）。

考虑一个不执行 CORS 标头的服务器，但只是盲目地假设您在同一个来源，并返回 JSON... ...现在，假设 Fetch 允许您跨源请求资源（确实如此）。

模式规定，如果发出这种请求，并且给出这种响应，那么负载应该对 Fetch 请求的接收者完全不透明......这意味着您可以获得响应，只是像往常一样，但实际上无法让 body 解析或使用它。

这是一件大事，既让您能够跨来源发出请求，又让浏览器保持安全er。

它甚至还有实际应用，例如预加载/预取数据，可能某些主机 API 会使用（例如 <img> 或 <video>），这些接口比运行 JS 的沙箱。

这些相同类型的概念也适用于 ServiceWorker 和缓存不透明 blob 的来源，这些来源绝对不是您的来源（例如，在 service-worker 级别缓存和提供 Gravatar 图像）。

【讨论】：

【解决方案2】：

Fetch API 在设计上公开了浏览器内部用于获取的相同原语。

mode 是这些原语之一。它不仅用于 Fetch 规范中定义 Fetch API 的部分——因为 Fetch 规范除了定义 JavaScript API 之外，还定义了浏览器如何在内部处理各种类型的获取的低级算法。

在 HTML 规范等规范中定义的浏览器内部算法引用了 Fetch 规范中的那些低级算法，并依赖于设置 mode 和 fetch 的其他方面。

例如，在 HTML 规范中，fetch a classic worker script 算法以此开头：

要获取一个经典的工作脚本，给定一个 url，一个 fetch 客户端设置对象、目的地和脚本设置对象，运行这些步骤。该算法将使用 null（失败时）或新的异步完成 classic script（成功时）。

让 request 成为一个新的 request，其 url 是 url，client 是 获取客户端设置对象，@987654326 @ 是目的地，mode 是“same-origin”，credentials mode 是“same-origin”，parser metadata 是“not parser-inserted”，其use-URL-credentials flag 已设置。

注意 «Let 请求 be a new request» 和 «mode is "same-origin"» 部分 —注意request 的超链接转到https://fetch.spec.whatwg.org/#concept-request，mode 的超链接转到https://fetch.spec.whatwg.org/#concept-request-mode。

因此，HTML 规范需要为请求设置“same-origin”模式设置——以便指定浏览器在进行某种类型的获取时在内部使用的行为。

这就是为什么 Fetch 规范需要为 fetch 提供特定模式的原因。除此之外，Fetch API 提供设置“same-origin”模式的能力的原因是（如上所述）与允许您作为 Web 开发人员访问浏览器可以访问的相同原语的目标保持一致在内部进行提取时。

您可能永远不会发现需要 Fetch API 公开的所有各种模式 — 您不太可能想要使用 navigate 模式 — 但它们仍然存在，因为它们代表了完整的集合任何给定提取场景所需的模式（包括仅可能由浏览器内部使用的场景）。

【讨论】：