Re: CSP 1.1: Paths in source list definitions.

On Sat, 13 Oct 2012 09:56:35 +0200, Adam Barth <w3c@adambarth.com> wrote:

>> One open question is how we would handle query strings. Do we want to
>> support 'example.com/js/thisfile.js?id=2'? If so, how would we handle a
>> request for 'example.com/js/thisfile.js?extra=param&id=2'? Is that a  
>> match?
>> How about 'example.com/js/thisfile.js?id=2&extra=param'?
> IMHO, we shouldn't support query strings.  This feature is most useful
> for restricting to a known-safe directory.

What do you mean? Should not support query strings, as in:

   example.com/js/thisfile.js?id=2

would be blocked, when CSP allows /js/thisfile.js?

That does make sense, however: query strings are often used to bust the  
cache when you do updates to static resources. So you would presumably  
allow /js/thisfile.js?28 and then when you update it it changes to  
/js/thisfile.js?29 ?

I'm totally fine with that. Actually using full paths  
(http://example.com/js/thisfile.js) rather than the full folder  
(http://example.com/js/), or even the origin itself (http://example.com)  
are a sign of OCD anyway - so if you specify a file it would make sense  
for it to only be called like that.

-- 
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

Received on Monday, 15 October 2012 14:16:13 UTC