HTML's "navigate" algorithm should handle 'X-Frame-Options' and CSP's 'frame-ancestors'

[mikewest]

See whatwg/fetch#302 where I initially filed this request. @annevk's suggestion that we handle the header inside the navigation algorithm (probably as step 21, after the response checks?) SGTM.

This will require some changes to CSP as well to move frame-ancestors from a response check in Fetch to a new check in the navigate algorithm.

[annevk]

This should be pretty easy to add now.

[mikewest]

Poking at this today. For frame-ancestor, I expect to add the relevant hooks to CSP, and, then call them from https://html.spec.whatwg.org/#process-a-navigate-response. For X-F-O, I'll make up something that at least somewhat aligns with RFC7034.

[mikewest]

"Pretty easy to add", he says.

Basically, we didn't think about this enough, and it's more subtle than I though, because we need the source browsing context's policy in some cases (form-action), and the target browsing context's parent's policy in others (frame-src), and the response's policy in still others (frame-ancestors). I think these two hooks give me the tools I'll need to poke at things in CSP, but I wonder if there's a better way...

WDYT?

[annevk]

One way to do form-action is to just hook it directly in form submission. And just navigate to a network error if it blocks. If it's specific to forms invoking navigate we might as well keep it there.

The others remain complicated.

[mikewest]

Hooking directly into form submission wouldn't catch redirects, would it? I think we need to live in navigate for that to work.

[annevk]

Good point.

[mikewest]

Are you waiting on me for this PR? (Sorry, I've been out for almost two weeks, so I'm trying to page this back in....)

[annevk]

Yeah, the review comments are not addressed yet I thought.