- From: Tobie Langel <tobie@w3.org>
- Date: Thu, 18 Jul 2013 23:40:24 +0200
- To: Brad Hill <hillbrad@gmail.com>
- Cc: Peter Linss <peter.linss@hp.com>, public-test-infra <public-test-infra@w3.org>, Richard Ishida <ishida@w3.org>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Anne van Kesteren <annevk@annevk.nl>, Phillips, Addison <addison@lab126.com>
On Thursday, July 18, 2013 at 11:19 PM, Brad Hill wrote: > This seems like a good 98% solution. > Heh. I was aiming for 80%. This is a bigger win than expected. > But in WebAppSec, we need a bit more sophisticated capability. For CSP, we need to be able to verify reports are sent, and reports are sent based on a URI in the header. So we do something like: https://servername/csp/support/report.php?id=<randomnumber>, so we can go and query later on <randomnumber> to see if the report contained what we expected. > > We also really want to be able to make sure that whatever policy string that was set in the header is known definitively to the DOM for testing purposes. (again, so we can verify reporting, e.g.) In PHP we just set the policy string as a variable and can access it when we set the header, and later when checking the report, and know they're never out of sync. That would be much harder under this system. (I guess we could have the same string as a set-cookie and read that from the DOM..but ugh) > > I don't mean to suggest complicating this particular proposal, only that some groups may still need fully dynamic server-side capabilities. Absolutely. We might be able to meet some of your requirements (or those of say, the XHR spec) through dedicated API/components, but if not, we'll of course provide full server-side access. --tobie
Received on Thursday, 18 July 2013 21:40:34 UTC