On Mon, Oct 15, 2012 at 4:15 PM, Odin Hørthe Omdal <odinho@opera.com> wrote: > 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<http://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<http://example.com/js/thisfile.js?extra=param&id=2>'? >>> Is that a match? >>> How about 'example.com/js/thisfile.js?**id=2&extra=param<http://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<http://example.com/js/thisfile.js?id=2> > > would be blocked, when CSP allows /js/thisfile.js? > I think he means the opposite: whitelisting 'example.com/js/thisfile.js' would allow 'https://example.com/js/thisfile.js?29', etc. We'd simply ignore the query portion of the source expression. That what I've experimentally implemented in https://bugs.webkit.org/show_bug.cgi?id=99250, and it seems like a reasonable solution. -- Mike West <mkwst@google.com>, Developer Advocate Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Received on Monday, 15 October 2012 14:36:24 UTC