- From: Anne van Kesteren <notifications@github.com>
- Date: Sun, 05 Jul 2015 09:55:10 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/66/118638144@github.com>
@igrigorik if we want to expose more about redirects we need a new protocol similar to CORS. As I said before, that warrants a new issue. I've been trying to evaluate how we can minimize the complexity here (please verify my analysis): * This is only relevant when the request context is a https://fetch.spec.whatwg.org/#navigation-request-context * Those are always same-origin requests and therefore cannot return opaque responses. * If you then get back an opaque response you know that a redirect happened. * However, if we provide an option to disable redirects, an opaque response indicates a redirect. Since you're guaranteed it's a redirect, given an option to disable them, we should just expose it as a "redirect" (new type of response, identical to opaque except for its type and exposure of url as that is identical to the request url). We could then enforce that you can only return such a "redirect" response to navigation request contexts (that have redirect mode on manual), coupled with a same-origin restriction. (`Response.redirect()` would continue to generate "default" responses from which you can observe all details.) I don't see any obvious issues with this, other than perhaps the difficulty for the "navigate" algorithm to handle redirects by itself: * Cloning of request's body. * Dealing with `Location` headers. * ? None of that is well defined at the moment. --- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/66#issuecomment-118638144
Received on Sunday, 5 July 2015 16:55:37 UTC