Replicate Content-Security-Policy into remote frame proxies.

content/common/frame_replication_state.h

Index: content/common/frame_replication_state.h
diff --git a/content/common/frame_replication_state.h b/content/common/frame_replication_state.h
index f6373491a19478b5173e51e346fb6c79ca3cf8da..9cb88af432b95953bd2fc6d1b1a5ef9c34911510 100644
--- a/content/common/frame_replication_state.h
+++ b/content/common/frame_replication_state.h
@@ -5,7 +5,11 @@
 #ifndef CONTENT_COMMON_FRAME_REPLICATION_STATE_H_
 #define CONTENT_COMMON_FRAME_REPLICATION_STATE_H_
 
+#include <string>
+#include <vector>
+
 #include "content/common/content_export.h"
+#include "content/common/content_security_policy_header.h"
 #include "url/origin.h"
 
 namespace blink {
@@ -79,6 +83,10 @@ struct CONTENT_EXPORT FrameReplicationState {
   // scratch.
   std::string unique_name;
 
+  // Accumulated CSP headers - gathered from http headers, <meta> elements,
+  // parent frames (in case of about:blank frames).

[alexmos, 2016/05/11 19:46:41]

Sanity check: if a page dynamically removes a <meta> element with a CSP header,
does that affect the current CSP at all?  I'd expect not, but wanted to
double-check.

[Łukasz Anforowicz, 2016/05/11 23:14:48]

It doesn't.  I am basing this on the fact that ContentSecurityPolicy::m_policies
is only modified in ContentSecurityPolicy::addPolicyFromHeaderValue (and we only
append to the list of policies).

Also - interestingly, changing the value of <meta> element's content attribute
should also have no effect.  I am basing this on
https://www.w3.org/TR/CSP2/#delivery-html-meta-element.

[alexmos, 2016/05/12 22:37:24]

Acknowledged.

+  std::vector<ContentSecurityPolicyHeader> accumulated_csp_headers;
+
   // Whether the frame is in a document tree or a shadow tree, per the Shadow
   // DOM spec: https://w3c.github.io/webcomponents/spec/shadow/
   // Note: This should really be const, as it can never change once a frame is