Re: [fetch] Introduce HTTP-redirect fetch (#194)

> + <span title=concept-filtered-response>filtered response</span>, and <var>response</var>'s
> + <span title=concept-internal-response>internal response</span> otherwise.
> +
> + <li><p>Let <var>location</var> be the result of <span title=concept-header-parse>parsing</span>
> + `<code title>Location</code>` in <var>actualResponse</var>'s
> + <span title=concept-response-header-list>header list</span>.
> +
> + <li><p>If <var>location</var> is null, return <var>response</var>.
> +
> + <li><p>If <var>location</var> is failure, return a
> + <span title=concept-network-error>network error</span>.
> + <!-- only Gecko does this; and even that is currently more complicated -->
> +
> + <li><p>Let <var>locationURL</var> be the result of
> + <span data-anolis-spec=url title=concept-url-parser>parsing</span> <var>location</var> with
> + <var>request</var>'s <span title=concept-request-current-url>current url</span>.

When the service worker creates a redirect, there is no response URL. If the redirect came from the server, this only matters if the service worker stored the opaque response and served it against a different request url later on. Or am I missing something? I suppose foreign fetch might make this more complicated.

In that case though, I guess you're right that you might want to use the URL of the response rather than that of the request, otherwise you could figure out things about the redirect. Intriguing. Probably a good follow up issue.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/194/files#r51457018