This is caused by the new Uri.resolve() method.
I took a look at this and found that this fix gets us most of the way
there:
if (getAuthority() != null) {
pathStack.addFirst(""); // get an initial / on the front..
}
return Join.join("/", pathStack);
However there's still an issue where the content rewriting depends
upon java.net.URI throwing an IllegalArgumentException when parsing a
malformed URI string we generate.
Basically here's what happens:
javascript:doevil() is parsed as a Uri
this is passed to java.net.URI
which results in doevil() being set as 'schemeSpecificPart'
UriBuilder then constructs a new Uri, however we have no concept
of this.
Later on...
the old Uri.resolve() code uses java.net.URI to do it's resolution.
During this process we try to parse the URI 'javascript:' (as
created above with UriBuilder)
this throws an illegalargumentexception
Someone remind me why we created our own Uri class again? Looking
through the source
http://www.google.com/codesearch/p?hl=en#TTY8xLpnKOE/src/share/classes/
java/net/URI.java
You find there's a ton of corner cases handled there that we'll be
rehashing forever... might it make more sense to subclass
java.net.URI and fix up the parts that we don't like?
On Mar 27, 2009, at 4:00 AM, chico charlesworth wrote:
The shindig gadgets module build is failing since revision 758884
(checked
in 26th at 10:15pm GMT)
- changes: Implements Uri.resolve(...) natively instead of in terms
of
java.net.URI.
Failed tests:
enforceCssImportLinkRewritten
(org
.apache.shindig.gadgets.render.SanitizedRenderingContentRewriterTest)
enforceCssImportBadLinkStripped
(org
.apache.shindig.gadgets.render.SanitizedRenderingContentRewriterTest)
Can someone fix?
Cheers
Chico
