- From: Brad Hill <hillbrad@gmail.com>
- Date: Tue, 3 Jun 2014 20:01:38 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WebAppSec WG <public-webappsec@w3.org>
Received on Wednesday, 4 June 2014 03:02:06 UTC
Sorry for the delay, Anne. We discussed this on the May 7 call, and don't know that it makes the most sense to structure frame-ancestors in terms of Fetch. In the case of this directive, we've already fetched the resource, but decide not to render it based on headers it was sent with. So it might be more analogous to the case of receiving broken XML that cannot be rendered, rather than being pre-evaluated in the context of the parent and returning a network error if forbidden. Make sense? -Brad On Thu, Apr 24, 2014 at 8:32 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > It's not entirely clear to me how we should model this directive. > http://fetch.spec.whatwg.org/#concept-fetch has a placeholder hook for > CSP now. And as I mentioned before I added request contexts and a link > back to the global environment. Do we also need a pointer to the API > responsible for the fetch? We might need it for priorities in HTTP/2.0 > I believe... But maybe there's a better way for this directive? > > > -- > http://annevankesteren.nl/ > >
Received on Wednesday, 4 June 2014 03:02:06 UTC