- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 26 Jun 2013 11:08:21 +0100
- To: Adam Barth <w3c@adambarth.com>
- Cc: WebAppSec WG <public-webappsec@w3.org>
On Wed, Jun 26, 2013 at 5:19 AM, Adam Barth <w3c@adambarth.com> wrote: > On Tue, Jun 25, 2013 at 3:31 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> Why does https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#reporting >> use a different algorithm to derive an origin from a URL? > > Different from what? From: https://tools.ietf.org/html/rfc6454#section-6.2 >> Also, it >> seems somewhat confusing to have this new origin type, actual origins, >> and URLs, in the same value space. Even though the property says >> "blocked-uri" you wouldn't be able to parse it with a URL parser and >> get a sensible result. > > I'm not sure I understand. Can you give a specific situation where > something problematic happens? Using a URL parser just "data" would fail to parse. It seems the field is actually a union of schemes, origins, and URLs. > What we've tried to do with this field is include as much information > about the blocked URI as we can do safely. In the same-origin case, > we can include the URI with the fragment removed. For the > cross-origin case, we need to strip out the path and query portions as > well. I guess we could do that directly instead of converting to an > origin and then serializing back to ASCII. We'd just have to be > careful to do something sensible with data URIs. Hmm mkay. -- http://annevankesteren.nl/
Received on Wednesday, 26 June 2013 10:08:49 UTC