Re: some further Comments on Content Security Policy 1.0 Editor's Draft

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