Bug 109429 – CSP reports for blocked 'data:' URLs should report the scheme only.

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Mike West]

https://dvcs.w3.org/hg/content-security-policy/rev/001dc8e8bcc3 changed the CSP 1.1 spec to require that blocked URLs that don't map well to the web (e.g. 'data:', 'javascript:', etc.) be stripped down to their scheme in violation reports. I'm not sure what the best way to do that actually is... The question sorta maps to 'KURL::isHierarchical()', but not really. The current patch uses 'KURL::canSetHostOrPort()' (which maps to 'isHierarchical()'), but there's likely a better way.

Adam, what do you think?

[Mike West]

Created attachment 187566 [details]
Patch

[Adam Barth]

Comment on attachment 187566 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=187566&action=review

> Source/WebCore/page/ContentSecurityPolicy.cpp:1634
> +        if (blockedURL.canSetHostOrPort())

I'd use isHierarchical rather than canSetHostOrPort, but I think they're the same.

[Mike West]

(In reply to comment #2)
> (From update of attachment 187566 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=187566&action=review
> 
> > Source/WebCore/page/ContentSecurityPolicy.cpp:1634
> > +        if (blockedURL.canSetHostOrPort())
> 
> I'd use isHierarchical rather than canSetHostOrPort, but I think they're the same.

KURL::isHierarchical is private, which is why I used this (which, as you say, is simply an alias). Should I move it out into the public API?

[Adam Barth]

SUre.

[Mike West]

Created attachment 187628 [details]
Patch

[Mike West]

Comment on attachment 187628 [details]
Patch

Whoops. Carrying over Adam's r+. Meant to just throw this at the bots before CQing.

[WebKit Review Bot]

Comment on attachment 187628 [details]
Patch

Clearing flags on attachment: 187628

Committed r142506: <http://trac.webkit.org/changeset/142506>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.