- From: Mike West <mkwst@google.com>
- Date: Tue, 20 Jan 2015 11:45:54 +0100
- To: Brian Smith <brian@briansmith.org>
- Cc: Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=ei2yceMFEY4bwCcO7c992N3fuH39bOd5bh-Mc-Rsag0g@mail.gmail.com>
On Mon, Jan 19, 2015 at 11:07 PM, Brian Smith <brian@briansmith.org> wrote: > Looks good. I think it would be good to also list the things that > aren't supported in <meta> in a note in section 3.3, which specifies > the <meta> element. This way, the limitations of the <meta> element > become clearer We have this in step 5 of the algorithm. I don't think that duplicating it in a note would be terribly helpful. > Additionally, I think there should be a suggestion > that the user agent should issue a warning when a directive is > detected in a <meta> element that isn't supported in the meta element. > Added this in https://github.com/w3c/webappsec/commit/91f262bf836859fe94c54d00a7f907ca67e7b638 (which has the nice side-effect of highlighting step 5 :) ). Also, is it still intended that Content-Security-Policy-Report-Only > isn't allowed in <meta>? I thought that this restriction was included > back when <meta>- and header-field- specified policies were mutually > exclusive, but now that those rules have changed, does it still make > sense to prohibit <meta > http-equiv=Content-Security-Policy-Report-Only>? > This goes along with the `report-uri` restriction; it doesn't make sense to allow a report-only policy if we're not allowing a reporting endpoint, does it? -mike -- Mike West <mkwst@google.com>, @mikewest 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.)
Received on Tuesday, 20 January 2015 10:46:42 UTC