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>.

Yeah, that seems like a security vulnerability. Since you can figure out where a cross-origin redirect goes to. So we need to do one of these:

* Resolve against the response URL (but this does not work as a generic solution, see above)
* Check that the request URL is equal to the response URL when response's type is "opaqueredirect".

Or is there a better solution that I'm missing? Either way, this seems like a separate issue from this rewrite, no?

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

Received on Tuesday, 2 February 2016 08:49:11 UTC