- From: =JeffH <Jeff.Hodges@KingsMountain.com>
- Date: Tue, 11 Sep 2012 13:41:50 -0700
- To: Adam Barth <w3c@adambarth.com>
- CC: W3C Web App Security WG <public-webappsec@w3.org>
Adam replied: > On Thu, Jul 5, 2012 at 8:42 AM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote: >>>> understood. In any case, the spec is silent about parsing errors AFAICT >>>> (yes?). Mentioning them (in the framework section), and their >>>> ramifications >>>> would be a good idea it seems. >>> >>> There isn't a notion of a parse error in the spec. There's the set of >>> strings that servers ought to generate and a requirements for how user >>> agents must interpret every possible input. >> >> Ok, thx, if i understand correctly, directive value tokens that don't match >> the source-expression ABNF is ignored by the "parse a source list" algorithm >> and is simply not added to the resultant set of source expressions in step >> 3. >> >> So for CSP 1.0, if one has a directive with a value like so.. >> >> script-src http://my-site.com/js/ >> >> ..which doesn't match any source-expression grammar, > > Ah, you're right that there's a subtle bug. > > "For each token returned by splitting source list on spaces, if the > token matches the grammar for source-expression, add the token to the > set of source expressions." > > should read > > "For each token returned by splitting source list on spaces, if the > token matches the grammar for source-expression or ext-host-source, > add the token to the set of source expressions." > > Then the net result will be treating it like the following: > > script-src http://my-site.com Ok. I suggest, though, that a clear example be added to the spec illustrating that (in CSP 1.0) source-list components of ext-host-source syntax (eg http://my-site.com/js/) will be matched as if they were only of host-source syntax, i.e. any paths will be ignored. =JeffH
Received on Tuesday, 11 September 2012 20:42:15 UTC