获取API - 重定向有哪些用途:手动

Question

我最近一直在玩Javascript Fetch API.据我了解,默认情况下,所有重定向都是透明处理的,最后我得到了重定向链中最后一次调用的响应.

但是,我可以使用{redirect:'manual'}调用fetch,在这种情况下,它会返回一个没有可用信息的opaqueredirect响应.来自https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect

opaque-redirect过滤响应是一个过滤后的响应,其类型为"opaqueredirect",状态为0,状态消息为空字节序列,标头列表为空,body为空,预告片为空.

https://fetch.spec.whatwg.org/#http-fetch表示如果重定向设置为'manual',则响应将变为opaqueredirect:

切换请求的重定向模式:
...
- manual
    设置对opaque-redirect过滤响应的响应,其内部响应为actualResponse.

规范还说:

换句话说,不透明的过滤响应和不透明重定向过滤的响应几乎与网络错误无法区分.

鉴于这一切,为什么在使用Fetch API时会将重定向设置为手动？对我来说似乎没用.是否存在有用的用例？

Answer 1

我认为简短的回答是:除非您正在使用https://github.com/whatwg/fetch/issues/66描述的服务工作者代码,否则您不会想要redirect: 'manual'.

更长的回答:

在HTML规范似乎需要浏览器的初始设置重定向模式manual时,浏览器开始导航至某个资源,在那之前......(再)与重定向模式未设置这样做呢？(在这种情况下,它默认返回follow.)我不明白为什么规范中的算法会这样做,但猜测它必须与处理导航失败的情况有关.无论如何,我相信这是manual重定向模式在任何规范中的唯一用途.

无论如何,Fetch API旨在公开浏览器在提取中使用的所有相同原语,但这并不意味着Web应用程序代码中的这些原语总是有很好的用途(与浏览器本身使用的原语相比)原语).

所以我认为Fetch规范过去要求即使你可以调用API redirect: 'manual',浏览器也会抛出 - 如果你这样做 - 我想因为当时没有人提出任何有效的理由为它设置除浏览器以外的任何情况做导航.

但是由于https://github.com/whatwg/fetch/issues/66描述了(角落)案例,redirect: 'manual'在服务工作者代码中需要这种行为似乎已经改变了.

您可以在Fetch API中设置但在Web应用程序代码中实用性很低的类似情况mode: 'no-cors'.最初添加它只是因为浏览器将其用于某些请求,因此Fetch API会公开它.但这是另一个仅限于服务工作者的实用程序的情况 - 缓存响应以便在以后服务,而无需检查响应(这会mode: 'no-cors'阻止Web应用程序代码执行).