响应 headers 不适用于 'redirect: manual' 的提取请求

Response headers not available for fetch request with 'redirect: manual'

我在做

        console.log("navigating");
        var rsp = await fetch(params.url, {
            credentials: "include", redirect: "manual", mode: "cors"
        });
        console.log(rsp);
        rsp.headers.forEach(console.log);

        console.log(rsp.headers.get('Location'));
        console.log(rsp.headers.get('location'));

以及来自 chrome 开发工具的响应 headers:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost:4400
Access-Control-Expose-Headers: Location
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 0
Date: Fri, 05 Oct 2018 12:48:21 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: http://localhost/test

给予

Response 
body: (...)
bodyUsed: falseheaders: 
Headers {}
ok: false
redirected: false
status: 0
statusText: ""
type: "opaqueredirect"
url: "..."

index.ts:161 null
index.ts:162 null

是否无法在重定向响应中获得响应 headers?

Is it not possible to get response headers out on redirect response?

不,这不可能。 Fetch 规范中的要求阻止了它。

对于 manual 重定向模式,问题显示的内容是预期的:暴露给前端 JS 的 headers object 在对 redirect: "manual" 请求的响应中预计为空。

当请求设置 manual 重定向模式时,响应类型为 opaqueredirect。有关其影响的信息位于 https://developer.mozilla.org/en-US/docs/Web/API/Response/type:

opaqueredirect: The fetch request was made with redirect: "manual". The Response's status is 0, headers are empty, body is null and trailer is empty.


该 MDN 文章中的那些细节直接基于 Fetch 规范的以下部分:

https://fetch.spec.whatwg.org/#concept-request-redirect-mode

A request has an associated redirect mode, which is "follow", "error", or "manual".

"manual": Retrieves an opaque-redirect filtered response when a request is met with a redirect so that the redirect can be followed manually.

https://fetch.spec.whatwg.org/#concept-filtered-response-opaque-redirect

opaque-redirect filtered response is a filtered response whose type is "opaqueredirect", status is 0, status message is the empty byte sequence, header list is empty, body is null

an opaque filtered response and an opaque-redirect filtered response are nearly indistinguishable from a network error