- From: Anne van Kesteren <notifications@github.com>
- Date: Tue, 02 Feb 2016 00:48:42 -0800
- To: whatwg/fetch <fetch@noreply.github.com>
- Message-ID: <whatwg/fetch/pull/194/r51539155@github.com>
> + <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