- From: Mike West <mkwst@google.com>
- Date: Wed, 4 Jun 2014 09:42:39 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Brad Hill <hillbrad@gmail.com>, WebAppSec WG <public-webappsec@w3.org>
- Message-ID: <CAKXHy=deFgU3P=mu_E9Q6RPdR28gAozgYApVof-p2854T5S34w@mail.gmail.com>
Well, there's already a lot of magic hidden away in http://fetch.spec.whatwg.org/#concept-http-network-or-cache-fetch. All of the TLS-handshake, for instance. I don't know what level you'd like Fetch to dive down to. Frame ancestors seems like something we could reasonably include in Fetch (perhaps by pointing to a new hook in CSP, and passing in the request and response). I'm not really sure where to stop, however. At some point we reach the transport layer, which doesn't seem like what Fetch should be concerned with. I guess there's a stopping point somewhere between those two. -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 9:33 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Jun 4, 2014 at 9:18 AM, Mike West <mkwst@google.com> wrote: > > 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. > > If it's not Fetch it seems like this should be coordinated with HTML > at all the places where this would be applicable. Otherwise we lose > track of ordering. > > > -- > http://annevankesteren.nl/ >
Received on Wednesday, 4 June 2014 07:43:28 UTC