Fix URI resolution and extract javascript URLs.

Prior, we resolved URIs in HTML inconsistently.
We completely ignored <base href> URIs, and instead got the URI
from the FilePosition.  This is problematic for content parsed
without debugging on.  This CL does not entirely address that problem
but adds a pass so that when the base URI is known, we correctly
apply it.

This change also consolidates code that finds and parses embedded
content: styles and scripts in HTML.

A following CL will have to thread the base URI reliably through from
our external APIs.  That will require coordination with clients, so is
out of scope for this change.


Submitted @3931

[Jasvir, 2009-12-22 23:44:06]

LGTM

http://codereview.appspot.com/180091/diff/63/1049
File src/com/google/caja/lexer/escaping/UriUtil.java (right):

http://codereview.appspot.com/180091/diff/63/1049#newcode125
src/com/google/caja/lexer/escaping/UriUtil.java:125: // implementation instead.
What is the bug in java.net.URI?  The result below looks correct to me.  The
spec suggests that after resolving the URI if any ".." remain in the path, the
UA can choose to treat it is part of the final URI or not traverse it etc.

[MikeSamuel, 2009-12-24 07:08:39]

http://codereview.appspot.com/180091/diff/63/1049
File src/com/google/caja/lexer/escaping/UriUtil.java (right):

http://codereview.appspot.com/180091/diff/63/1049#newcode125
src/com/google/caja/lexer/escaping/UriUtil.java:125: // implementation instead.
On 2009/12/22 23:44:06, jasvir wrote:
> What is the bug in java.net.URI?  The result below looks correct to me.  The
> spec suggests that after resolving the URI if any ".." remain in the path, the
> UA can choose to treat it is part of the final URI or not traverse it etc.

From http://www.ietf.org/rfc/rfc3986.txt

A.  If the input buffer begins with a prefix of "../" or "./",
           then remove that prefix from the input buffer; otherwise,