On Tue, Jul 1, 2014 at 5:18 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > So there are a few things to unpack here. > > If I do a window.open(), then I now have two top-level browsing contexts. > One of them is auxiliary, one is not, right? Its possible to then navigate > that browsing context via more window.open() calls targeting that auxiliary > browsing context name, anchor clicks in that browsing context or others, > location sets, form submissions, etc. > > So if what we really want to know is whether a navigation is associated with > an auxiliary browsing context or not, I think doing that via the request > context isn't a good fit; it's somewhat orthogonal to how the request is > being performed.
https://github.com/slightlyoff/ServiceWorker/issues/352 >> A request's origin is set by the API that initiates the fetch. > > OK. So this is the origin of the thing that triggered the fetch, basically? Yes. >> A response does not really carry an origin. > > I guess that depends on how you think about redirects. The origin of a > response is determined based on the URI it was actually gotten from, which > may not be the same URI that the consumer passed into fetch initially, > right? Yes. And if you used "no CORS" and you went cross-origin > same-origin, you end up with a response whose type is tainted. The idea of this model is that a response only gives access to what you're allowed to based on the request you made and passed to fetch. If you have special privileges (such as <img> does) you can get to the internal response from a response and get the actual bytes out for displaying (at your own risk). Of course, ideally only legacy APIs do silly things like that. -- http://annevankesteren.nl/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
