[XALANJ-758] Bad URI absolutizing

• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Affects Version/s: 2.2.x
• Component/s: Other
• Environment: Operating System: Other; Platform: All
• Bugzilla Id: 5701
• Assignee: Shane Curcuru
• Reporter: Gregor Karlinger
• Created: 05/Jan/02 12:50
• Updated: 02/Sep/04 21:06
• Resolved: 02/Sep/04 21:06

Description

The methods getAbsoluteURI(String) and getAbsoluteURI(String, String)
are resolving relative URIs in a way which is not conforming with
section 5.2 of RFC 2396. Below are the interesting snippets of the
code:

133: else if (url.startsWith("file:") && url.charAt(5) != '/')
134:

{ 135: url = getAbsoluteURIFromRelative(url.substring(5)); 136: }

156: if(urlString.startsWith("file:") && urlString.charAt(5) != '/')
157:

{ 158: needToResolve = true; 159: }

Section 5.2, bullet 3) of RFC2396 states:

"3) If the scheme component is defined, indicating that the reference
starts with a scheme name, then the reference is interpreted as an
absolute URI and we are done. [...]"

So, if the candidate URI starts with "file:" it must be considered absolute,
and there is no need to check whether the path component starts with "/" or
not.

The problem with the current code is that a Windows file URI like
file:c:/temp/foo.txt
is absolutized, although it is already an absolute URI with an opaque path
component. With a base URI of e. g. file:c:/base/bar.txt this results in
file:c:/base/c:/temp/foo.txt

/Gregor