On Fri, Mar 27, 2009 at 11:26 AM, Paul Lindner <[email protected]> wrote:
> 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?
It's final, so that doesn't work.
Uri was created to eliminate the dozens of sections in the code base that
were doing manual query string manipulation, in particular when dealing with
oauth code that has a more strict uri encoding scheme than the URI RFC calls
for.
We also needed a fast and efficient way to translate between mutable and
immutable URIs, so that you can do this:
new UriBuilder(oldUri).setScheme("https").toUri();
instead of:
new URI("https", oldUri.getSchemeSpecificPart(), oldUri.getUserData(),
oldUri.getPath(), oldUri.getPath(), oldUri.getQuery(),
oldUri.getFragment());
However, I did make an explicit point to re-use java.net.URI's parser and
resolver because, as you said, they've dealt with a lot of corner cases.
>
>
> 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
>>
>
>
