Adding Embedding-CSP HTTP header

third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.cpp

Index: third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.cpp
diff --git a/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.cpp b/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.cpp
index f48c327d1759bc01c79c10820b3bea924ce6eae8..13ce64109c85e1af270ace3008153432899a8ff2 100644
--- a/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.cpp
+++ b/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.cpp
@@ -34,6 +34,7 @@
 #include "core/loader/FrameLoader.h"
 #include "core/loader/FrameLoaderClient.h"
 #include "core/plugins/PluginView.h"
+#include "platform/RuntimeEnabledFeatures.h"
 #include "platform/weborigin/SecurityOrigin.h"
 
 namespace blink {
@@ -328,6 +329,10 @@ bool HTMLFrameOwnerElement::loadOrRedirectSubframe(const KURL& url, const Atomic
     if (policy != ReferrerPolicyDefault)
         frameLoadRequest.resourceRequest().setHTTPReferrer(SecurityPolicy::generateReferrer(policy, url, document().outgoingReferrer()));
 
+    if (RuntimeEnabledFeatures::embedderCSPEnforcementEnabled() && hasAttribute(HTMLNames::cspAttr) && !getAttribute(HTMLNames::cspAttr).isNull()) {
+        frameLoadRequest.resourceRequest().setHTTPHeaderField(HTTPNames::Embedding_CSP, getAttribute(HTMLNames::cspAttr));
+    }

[Mike West, 2016/09/27 12:14:50]

I think this is going to end up being the wrong place to put this logic. Despite
the name, `loadOrRedirectSubframe` doesn't actually appear to be called during
redirects (which suggests another set of tests to add :) ).

I think you'll have more luck adding the header in `FrameLoader`, which ends up
being responsible for creating a document and stuffing things into it.
`upgradeInsecureRequest()` is ~similar, and called in `FrameLoader::startLoad`.
It might be worth looking into that area of the code to see what you'd need to
do to move this logic around a bit to ensure that it covers the cases you care
about.

I think you'll need to replicate the `csp` value up to `FrameOwner` (that is,
both `HTMLFrameOwnerElement` and `RemoteFrameOwner`) in order to access it in
the loader. Look at things like `WebFrame::setFrameOwnerProperties` to see how
that works, as it's a bit complicated. Basically, the call to
`frameOwnerPropertiesChanged()` in the previous patch needs to grab the new CSP
value, replicate it up to the browser process from the renderer, and then push
it back down to the renderers it creates during navigation. It's probably best
to split that out into a separate patch.

+
     return parentFrame->loader().client()->createFrame(frameLoadRequest, frameName, this);
 }