提取API默认跨域行为 [英] Fetch API default cross-origin behavior

问题描述

提取规范表示默认的提取模式为否-cors'-

The Fetch Specifications say that the default Fetch mode is 'no-cors' -

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

A request has an associated mode, which is "same-origin", "cors", "no-cors", "navigate", or "websocket". Unless stated otherwise, it is "no-cors".

但是，我似乎注意到<$ c $之间的这种行为差异c> mode： no-cors 和未指定的模式。如该 JSFiddle示例中所示，将模式明确定义为 no-cors使得响应无法访问Javascript，虽然未指定模式，但使Response对象可用于调用方法。

But, I seem to be noticing this behavioral difference between mode: 'no-cors' and an unspecified mode. As demonstrated in this JSFiddle sample, explicitly defining mode as 'no-cors' makes the response inaccessible to the Javascript, while not specifying a mode makes the Response object available to the calling method.

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

Does explicitly specifying the fetch mode work differently from the default behavior that internally uses the same mode? What am I missing here?

推荐答案

对于跨域请求，Fetch算法设置响应污点 ，以请求 cors ，并要求使用 CORS协议执行

For cross-origin requests, the Fetch algorithm sets the "response tainting" for the request to cors and requires the fetch to be performed using the CORS protocol.

具体来说，请参见主要提取算法：

↪ 请求的当前网址来源与 request 的
起源相同，并且 CORS标志未设置

↪请求的当前网址方案是 数据

↪请求的模式是 导航 或 websocket

1. Se请求的响应变脏为 基本。

2.返回使用 request 执行方案获取的结果。 br>
…

↪ 请求的模式为 no-cors

1.将 request 的响应污点设置为 opaque 。

2 。返回使用 request 执行方案获取的结果。

…

↪否则

1.将请求的响应污点设置为 cors 。

2.返回使用带有 CORS标志<的请求执行HTTP提取的结果/ em>设置。

↪ request’s current url’s origin is same origin with request’s origin and CORS flag is unset
↪ request’s current url’s scheme is "data"
↪ request’s mode is "navigate" or "websocket"
1. Set request’s response tainting to "basic".
2. Return the result of performing a scheme fetch using request.
…
↪ request’s mode is "no-cors"
1. Set request’s response tainting to "opaque".
2. Return the result of performing a scheme fetch using request.
…
↪ Otherwise
1. Set request’s response tainting to "cors".
2. Return the result of performing an HTTP fetch using request with CORS flag set.

这是什么意思，如果请求URL与您的代码来源不同，并且方案不是数据，模式不是 navigate 或 websocket 或未明确设置为 no-cors ，然后达到否则条件，并使用< a href = https://fetch.spec.whatwg.org/#cors-protocol rel = nofollow noreferrer> CORS协议。

What it amounts to is, if the request URL isn’t same-origin with your code’s origin, and the scheme isn’t data and the mode isn’t navigate or websocket or isn’t explicitly set to no-cors, then that Otherwise condition gets reached, and the request gets made using the CORS protocol.

该说明将事情简化了一点，因为在请求具有触发浏览器进行预检的特征的情况下，在否则子步骤的上方只是一个子步骤，但是在这种情况下， 响应污点设置为 cors 。

That explanation simplifies things a bit because in the case where the request has characteristics that trigger the browser to do a preflight, there’s a substep just above that Otherwise substep that gets reached instead—but again in that case, the "response tainting" gets set to cors.

但是，我似乎注意模式：'no-cors'与未指定模式之间的行为差​​异。

But, I seem to be noticing this behavioral difference between mode: 'no-cors' and an unspecified mode.

区别在于，当您为请求显式设置 mode：'no-cors'时，在这种情况下，↪请求的模式为 no -cors 子步骤而不是 Otherwise 子步骤。

The difference is because when you explicitly set mode: 'no-cors' for the request, in that case the "↪ request’s mode is "no-cors"" substep gets reached instead of the Otherwise substep.

（尽管我认为也许可以对规范进行改进，以更清楚地表明当时的模式实际上并非默认为 no -cors -根据否则可能会得出的结论，除非另有说明，否则它是 no-cors 问题中引用的规范中的语句。）

(Though I think maybe the spec could be refined to make it more clear that the mode at that point doesn’t actually just default to no-cors—which is what you might otherwise conclude based on the "Unless stated otherwise, it is "no-cors"" statement from the spec cited in the question.)

如本JSFiddle示例所示，将模式明确定义为 no-cors '使得响应无法被Java脚本访问，

As demonstrated in this JSFiddle sample, explicitly defining mode as 'no-cors' makes the response inaccessible to the Javascript,

正确-这是因为它导致↪请求的模式为 no- cors 子步骤而不是否则子步骤。

Right—that’s because it causes the "↪ request’s mode is "no-cors"" substep in the "Main fetch" algorithm to get reached instead of the Otherwise substep.

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

while not specifying a mode makes the Response object available to the calling method.

因为否则然后进入子步骤，因此执行了启用CORS的提取。

Because the Otherwise substep does then get reached, so a CORS-enabled fetch gets performed.

显式指定获取模式与内部使用相同模式的默认行为不同吗？

Does explicitly specifying the fetch mode work differently from the default behavior that internally uses the same mode?

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

Yes, for a cross-origin request, explicitly setting mode: 'no-cors' forces the request to be made without using CORS, while leaving it unspecified causes it to be made using CORS.

但是如上所述，我认为也许应该对规范进行完善以使其更加清晰。

But as mentioned above, I think maybe the spec should get refined to be a bit more clear on this.

我认为除非另有说明，否则 no-cors 声明绝对不是该模式表示要指定使用 fetch（…）方法而未指定显式模式进行的请求最终将其模式锁定为 no-cors 。

I think that "Unless stated otherwise, it is "no-cors"" statement about the mode definitely isn’t meant to specify that requests that get made using the fetch(…) method without an explicit mode specified end up having their mode locked into no-cors.

这篇关于提取API默认跨域行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！