At some point, we'll want to drop the "X-WebKit-CSP" header completely. We won't be able to do that unless we have some baseline measurements. Assuming that it's very low cost, I think it makes sense to start measuring now. When we add the unprefixed header, we should likely measure that as well to track the transition. I'd suggest doing both measurements inside of ContentSecurityPolicy::didReceiveHeader. WDYT, Adam?
Created attachment 165286 [details] Patch
Note that dropping support for the prefixed header is easier than usual because it won't break any web sites. (It will just make them a bit less secure.) We also use the prefixed header in Chromium. Once we have the unprefixed header, we should switch Chromium over to using the unprefixed version.
(In reply to comment #2) > Note that dropping support for the prefixed header is easier than usual because it won't break any web sites. (It will just make them a bit less secure.) > > We also use the prefixed header in Chromium. Once we have the unprefixed header, we should switch Chromium over to using the unprefixed version. In the chrome://* pages, you mean? Good point. That said, there may be some areas where we could experimentally use some of the 1.1 bits and pieces. There might be inline script that 'script-nonce' could apply to, for instance. I'll file a bug to make sure we remember to talk about it.
(In reply to comment #3) > I'll file a bug to make sure we remember to talk about it. http://crbug.com/151857
Comment on attachment 165286 [details] Patch Clearing flags on attachment: 165286 Committed r129315: <http://trac.webkit.org/changeset/129315>
All reviewed patches have been landed. Closing bug.
> In the chrome://* pages, you mean? Good point. I also mean that content_security_policy in extension manifests maps to X-WebKit-CSP. We just need to grep the Chromium codebase for X-WebKit-CSP and update it.