Re: CSP, Fetch, and frame-ancestors

We should be able to determine whether or not to load the resource once we
process the HTTP response headers, we don't have to wait until the whole
resource is loaded. Whether or not we should do that in Fetch is a somewhat
open question, as it would happen somewhere in the middle of step 6.

I suppose we could add a new step 7 which checks the ancestor policy
(delivered via CSP or via X-Frame-Options) against the ancestor browsing
contexts associated with the request. I'm not sure how much of that we want
to bring into Fetch, though. Seems like a layering problem.

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Wed, Jun 4, 2014 at 5:01 AM, Brad Hill <hillbrad@gmail.com> wrote:

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