fetch API 中的 request.mode 有什么意义，特别是对于 cors 而言？

Question

查看新的 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可以实现？ “您可以使用它来确保始终向您的来源发出请求。” 但是，如果您要发送请求，或者其他开发人员可以访问代码，为什么不直接发送请求而不发送字段来指示其无效呢？

Answer 1

与服务器无关；无论如何，服务器都会收到请求。Fetch 和 XMLHttpRequest 都是如此。如果你的服务器很幼稚，做了一些愚蠢的事情，无论是谁从哪里传递它，这都是它自己的错，这与防止这种情况无关。

它与客户端让您看到的响应内容以及发送到服务器的内容有关（通过标头的凭据，与字段结合使用credentials）。

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

该模式规定，如果发出这种类型的请求，并给出这种类型的响应，则有效负载对于 Fetch 请求的接收者应该是完全不透明的……这意味着您可以获得响应，就像往常一样可以，但您实际上无法让主体解析或使用它。

这是一件大事，既允许您能够跨源发出请求，又保证浏览器的安全。

它甚至有实际的应用程序，例如预加载/预取数据，也许某些主机 API 将使用这些数据（例如<img>或<video>），其中这些接口被赋予比 JS 运行的沙箱更多的权限来访问外部数据。

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