- From: Odin Hørthe Omdal <odinho@opera.com>
- Date: Mon, 15 Oct 2012 16:15:22 +0200
- To: "Mike West" <mkwst@google.com>, "Adam Barth" <w3c@adambarth.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, "Tanvi Vyas" <tanvi@mozilla.com>, dveditz@mozilla.com
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